florian timm

Kurzzusammenfassung
Die vorliegende Arbeit ist Teil eines Projektes, das den modular austauschbaren Betrieb verschiedenster Sensorsysteme an einem Multikopter erlauben soll. Im Speziellen wird hier die Datenschnittstelle von einem Kompakt-Laserscanner Velodyne Lidar Puck VLP-16 zu einem Einplatinencomputer Raspberry Pi entwickelt und implementiert. Der Scanner selbst liefert hierbei die Daten in einem proprietären, binären Format. Diese sollen dann in ein einfach lesbares Format, beispielsweise eine ASCII-Datei, umgewandelt und gespeichert werden. Außerdem benötigen die Daten einem eindeutigen Zeitstempel, um diese später mit den anderen Sensorsystemen verknüpfen zu können. Diese Datentransformation sollte möglichst simultan zur Aufnahme erfolgen.

Auch Teil der Arbeit ist die Schaffung einer Steuerung der Laserscanneraufnahme. Hierfür wurde ein Bedienmodul erstellt, welches am Raspberry Pi direkt angeschlossen werden kann, sowie eine Weboberfläche entwickelt, die die Steuerung während des Fluges ermöglichen soll.

Abstract
This work is part of a project which should allow the modular interchangeable operation of various sensor systems on a multicopter. In particular, the data interface for the compact laser scanner Velodyne Lidar Puck VLP-16 to a single-board computer Raspberry Pi will be developed and implemented. The scanner itself provides the data in a proprietary, binary format, which should be converted and stored into an easy-to-read ASCII file. In addition, the data should be provided with a unique timestamp in order to be able to link it later with other sensor systems. This data transformation should be carried out approximately on real time.

Also a control of the recording of the laser scanner should be constructed in this work. For this purpose, an operating module was developed, which can be connected directly to the Raspberry Pi, as well as a web interface, which was integrated in the software. It should enable the control during flight.

Inhaltsverzeichnis

1  Einleitung

1.1  Problemstellung

Daten aus Airborne Laserscanning, dem Abtasten von Oberflächen mit einem Laserscanner aus der Luft, lassen sich für viele verschiedene Zwecke nutzen. Oft werden diese zur Erfassung von digitalen Geländemodellen verwendet, aber auch für die Erstellung von Stadtmodellen oder Vegetationsanalysen sind die Daten nutzbar. Aktuell werden als Trägersysteme des Laserscanners Helikopter oder Flugzeuge verwendet, die mit entsprechender Sensorik ausgerüstet sind. Diese Messmethode ist allerdings nicht für die Vermessung kleinerer Gebiete sinnvoll. Auch sind Aufnahmen von Fassaden, bei denen zwischen Häuserschluchten geflogen werden müsste, nicht möglich. Das Fluggerät wäre hierfür zu groß und gefährlich. Des Weiteren sind die Betriebs- und Anschaffungskosten sehr hoch, so dass eine solche Messung oft nur für sehr große Gebiete wirtschaftlich ist. Alternativ bietet sich die terrestrische Messung mittels Tachymeter oder auch per Laserscanner an, um kleinere Gebiete zu erfassen – hier benötigt die Aufnahme jedoch viel Zeit und Personal. Hinzu kommt, dass die Genauigkeit für viele Anwendungsfälle der 3D-Modelle zu hoch ist. Beide Möglichkeiten – die Messung aus der Luft oder vom Boden – sind sehr kostenintensiv. Ein Lösungsansatz hierfür wäre es, anstatt eines Helikopters als Trägersystem einen Multikopter zu nutzen. Jedoch ist die Tragfähigkeit für die meisten Laserscanning-Systeme nicht ausreichend. Daher basieren die 3D-Erfassungssysteme, die an Multikoptern genutzt werden, heutzutage meist auf photogrammetrischen Prinzipien, welche Luftbilder zur Erfassung nutzen. Hierzu muss jedoch ausreichend Beleuchtung vorhanden sein. Dies wiederum beschränkt den Einsatz der Systeme in Städten, in denen nur nachts für ausreichende Sicherheitszonen zum Betrieb von Multikoptern gesorgt werden kann. (Acevedo Pardo et al., 2015)

1.2  Projekt & Zielsetzung

Gesamtziel ist es, ein Laserscanning-System zu entwickeln, das von einem Multikopter getragen werden kann. Hierbei soll vor allem auf ein geringes Gewicht geachtet, aber auch die Kosten niedrig gehalten werden. Ein solches System könnte die Lücke zwischen terrestrischem und klassischem Airborne Laserscanning schließen (Ehring et al., 2016, S. 21f). Im Speziellen soll hier als erster Schritt die Datenverarbeitung des Laserscanners in einem solchen System realisiert werden. Hierfür soll ein Ein-Platinen-Computer vom Typ Raspberry Pi 3 die Speicherung und Aufbereitung der von einem Laserscanner des Modelles Velodyne Puck VLP-16 aufgezeichneten Laserpunktdaten übernehmen. Hierfür müssen entsprechende Schnittstellen zum Verbinden der Geräte in Hard- und Software entwickelt werden.

1.3  Struktur

Im Kapitel 2 werden zunächst die Grundlagen des luftgestützten Laserscannings erläutert. Außerdem wird die benötigte Hardware zur Durchführung eines solchen Airborne Laserscannings besprochen. Im Folgenden wird näher auf die Realisierung des Projektes eingegangen: Welche Hardware wurde verwendet und wie wurde diese angeschlossen (Kapitel 3), wie sollen die Daten verarbeitet werden (Kapitel 4), wie wird die Verarbeitung schließlich durchgeführt (Kapitel 5) und das System konfiguriert (Kapitel 6). Einzelne Komponenten werden in Kapitel 7 auf ihre Genauigkeit und Zuverlässigkeit geprüft. Zum Abschluss soll in Kapitel 8 noch ein Einblick in die Zukunft des Systems geworfen werden.

2  Grundlagen des Airborne Laserscannings

Airborne Laserscanning bezeichnet das Verfahren, bei dem ein Laserscanner, welcher an einem Fluggerät befestigt ist, Oberflächen kontaktlos dreidimensional erfasst (Beraldin et al., 2010, S. 1). Der Laserscanner liefert hierbei Daten in Form der Abstrahlrichtung des Strahles und der Entfernung, relativ zu seiner eigenen Ausrichtung und Position. Um diese lokalen Daten in ein globales System zu überführen, werden zusätzlich die Ausrichtung und die Position des Laserscanners zum Zeitpunkt der Messung benötigt (Beraldin et al., 2010, S. 22f). Diese Daten liefern im Normalfall eine inertiale Messeinheit (siehe Abschnitt 2.3) und ein Navigationssatellitenempfänger (siehe Abschnitt 2.2). Auf diese Bestandteile wird im Folgenden eingegangen. Anschließend werden einige bisherige Lösungsansätze zur dreidimensionalen Erfassung auf Basis von Multikopterplattformen vorgestellt.

2.1  Laserscanner

Ein Laserscanner besteht grundlegend aus einer Laser-Entfernungsmesseinheit und einer Ablenkeinheit. Für beide Teile gibt es verschiedenste Bauformen, die nachfolgend erläutert werden.

2.1.1  Entfernungsmessung

Für die Messung von Entfernungen mittels Laserscanner gibt es zwei meistgenutzte Verfahren:

Impulsmessverfahren Das bei Laserscannern am häufigsten eingesetzte Verfahren ist das Impulsmessverfahren, englisch time-of-flight genannt. Hierbei werden einzelne Laserimpulse ausgesandt. Mit dem Aussenden startet ein hochgenauer Timer seine Messung. Bei dem Eintreffen des an einer Oberfläche reflektierten Strahles bei dem Laserscanner wird der Timer gestoppt. Aus dieser gemessenen Laufzeit lässt sich die zurückgelegte Strecke des Lichtstrahles und somit die doppelte Entfernung zu der Oberfläche bestimmen. Hierzu wird der Brechungsindex $n$ des vom Laser durchlaufenen Mediums benötigt. Bei der Messung durch Luft lässt sich dieser aus der Messung von Temperatur-, Druck- und Luftfeuchte ausreichend genau bestimmen. Aus der bekannten Lichtgeschwindigkeit $c_0$ und der benötigten Zeit $t$ lässt sich dann die Entfernung $s$ mit der Gleichung 2.1 berechnen.

Phasenvergleichsverfahren Eine andere, für Airborne Laserscanning selten verwendete Methode, ist das Phasenvergleichsverfahren. Hierbei wird nicht direkt die Zeit gemessen, sondern die Phasenverschiebung eines kontinuierlichen Lichtstrahles, der mit einer Sinusschwingung amplitudenmoduliert wurde (Intensivitäts- bzw. Helligkeitsschwankungen). Hierdurch können weniger frequente Wellen (Modulationswellen) verwendet werden, wodurch sich bei guten Ausbreitungseigenschaften der hochfrequenten Trägerwellen die leichtere Verarbeitbarkeit von längeren Wellen ausnutzen lässt. Durch Messung des Phasenunterschiedes des Messstrahles, kann auf die Reststrecke der nicht vollständigen Phasen des Messstrahles geschlossen werden. Als Trägerwelle wird normalerweise Infrarotlicht verwendet, da dieses gute Ausbreitungseigenschaften hat. Die hierfür benötigte Modulationswelle wird durch einen Quarzoszillator erzeugt. Ein hier verbautes Quarzplättchen wird durch Anlegen einer Spannung in eine Schwingung versetzt, die Schwingung verstärkt und an den Infrarot-Laser geleitet, so dass dieser das modulierte Infrarotlicht aussendet. Die maximale, eindeutig messbare Entfernung ist direkt von der längsten verwendeten Wellenlänge, dem Grobmaßstab, abhängig: Da nur die Phasenunterschiede und nicht die Anzahl der vollständigen Schwingungen gemessen werden können, ist die maximale, eindeutige Streckenmessung genau halb so groß wie die maximale Wellenlänge (Messung von Hin- und Rückweg). Wenn längere Strecken als die halbe Wellenlänge gemessen werden, ist nicht bekannt, wie viele ganze Wellen das Licht schon zurückgelegt hat. Die Messung wäre mehrdeutig. Zur Messung der Phase werden die ausgesendete und die eingehende Messwelle mit einer Überlagerungsfrequenz vermischt, die aus diesen beiden hochfrequenten Wellen eine niederfrequente Welle erzeugt. Da die Genauigkeit der Phasenverschiebungsmessung begrenzt ist, wird durch Nutzung verschiedener Wellenlängen eine Genauigkeitssteigerung erreicht. Nach der groben Messung mit einer langen Wellenlänge, wird die Genauigkeit durch die Verwendung immer kürzerer Modulationswellen gesteigert. Eine grobe Messung ist jedoch vorher notwendig, da ansonsten die Anzahl der ganzen Schwingungen des Messstrahles unbekannt ist. (Witte & Schmidt, 2006, S. 311ff)

Zeitmessung Bei beiden Verfahren ist die genaue Zeitmessung ein Problem. Eine Möglichkeit dieser Messung ist die Nutzung eines Frequenzgenerators, welcher Zählimpulse erzeugt. Diese werden dann zwischen zwei Flanken der zu messenden Ausgangs- und Eingangswellen mehrfach gezählt, gemittelt und ergeben so zum Beispiel die Phasenverschiebung. Dieses Verfahren wird als digitale Messung bezeichnet. Eine andere Methode ist die analoge Messung. Hierbei öffnet die eine Flanke den Stromfluss zu einem Kondensator, die Flanke der anderen Welle schließt sie wieder. Aus der Ladung des Kondensators kann dann auf den Phasenwinkel und die Phasenverschiebung geschlossen werden. (Witte & Schmidt, 2006, S. 314f)

2.1.2  Ablenkeinheit

Bei den meisten Laserscannern ist nur eine Laserentfernungsmesseinheit verbaut. Um hiermit verschiedene Punkte messen zu können, muss der Laserstrahl durch geeignete Verfahren abgelenkt werden. Auch hierfür gibt es im Airborne Laserscanning verschiedenste Ansätze: (Pack, Robert T. et al., 2012, S. 23ff; Beraldin et al., 2010, S. 16ff)

Schwenkspiegel Der Laserstrahl wird auf einen schwingenden, flachen Spiegel gerichtet. Durch die Schwingung wird der Laserstrahl in einer Ebene nach links und rechts abgelenkt. Durch die Bewegung des Fluggerätes wird der Laser in Richtung der Schwingachse bewegt. Es entsteht eine Zick-Zack-Linie auf der Oberfläche als Messmuster.

Rotierender Polygon-Spiegel Bei diesem Typ dreht sich ein Prisma mit einem gleichseitigen Polygon als Grundfläche in der Achse der Flugbewegung. Seine Seiten sind verspiegelt und der Laser auf diese gerichtet. Von oben gesehen wird der Strahl somit immer nur in eine Richtung abgelenkt und springt beim Überstreifen der Kante wieder zurück auf die andere Seite. Es entsteht ein Streifenmuster.

Palmer-Scanner Bei dem Palmer-Scanner rotiert ein Flachspiegel um eine Achse, die fast senkrecht zur Spiegeloberfläche steht. Da der Spiegel nicht genau senkrecht auf dieser Achse montiert ist, beschreibt der auf den Spiegel gerichtete Laser einen Kreis. Durch einen im 45 Grad Winkel zur Achse stehenden Spiegel und einem sich in der Drehachse befindlichen Scanner können die Strahlen auch rechtwinklig abgelenkt werden und somit eine Ebene scannen. Dies wird häufig bei terrestrischen Laserscannern im Zusammenhang mit einer zweiten Drehachse angewandt.

Glasfaser-Scanner Der Glasfaser-Scanner nutzt zur Ablenkung zusätzlich Glasfasern, welche fest verbaut sind. Hierdurch sind die Ablenkungswinkel fest vorgegeben. Beispielsweise ein Polygonspiegel wie dieser zuvor beschrieben wurde, reflektiert den Messstrahl in das jeweilige Faserbündel.

Zusätzliche Achsen Zusätzlich zu den Spiegelmechanismen verfügen die terrestrischen Laserscanner über eine weitere Achse. Während bei dem Airborne Laserscanning die weitere Bewegung des Lasers durch die Fortbewegung des Fluggerätes durchgeführt wird, muss dies bei der terrestrischen Messung ein Motor übernehmen. Panorama-Laserscanner haben hierfür einen Drehmechanismus um ihre Hochachse. Bei Kamerascannern, diese messen nur eine quadratische Fläche wie eine Kamera, kann die zusätzliche Bewegung auch einfach durch einen zweiten Ablenkungsspiegel erfolgen. (Beraldin et al., 2010, S. 37)

Zusätzlich haben alle Ablenk- und Drehsysteme eine Messeinheit, die den Stand des Spiegels misst. Hierdurch lässt sich dann die Abstrahlrichtung des Lasers berechnen, beziehungsweise bei dem Faserlaser bestimmen, welches Faserbündel genutzt wurde. Die Richtung wird dann wiederum zur Berechnung von Koordinaten benötigt.

2.1.3  Oberflächeneffekte

Der vom Laser ausgesendete Impuls wird nur bei rechtwinklig zur Strahlenachse verlaufenden, ebenen Oberflächen als identischer, abgeschwächter Impuls zurückgestrahlt. Der Laser trifft bei der Messung nicht, wie idealisiert angenommen, punktförmig auf die Oberfläche, sondern stellt einen Kreis beziehungsweise bei schrägem Auftreffen eine Ellipse mit einer bestimmten Größe, dem sogenannten Footprint dar. Hierdurch ergeben sich je nach Oberfläche verschiedene Reflexionen: Bei einer zu dem Laserstrahl schrägen Oberfläche, wie einem Dach, wird das Signal geweitet, die Impulsdauer des reflektierten Strahles (Echo) wird verlängert, da dieser auf der Oberfläche zeitversetzt auftrifft. Ein anderes Phänomen sind mehrfache Echos. Dies tritt auf, wenn zwei unterschiedlich weite entfernte Oberflächen von einem Strahl getroffen werden – zum Beispiel bei der Messung von Gebäudekanten oder Bäumen. Abbildung 2.1 zeigt solche Echos in grafischer Form. (Beraldin et al., 2010, S. 28)

Laserscanner mit Impulsmessverfahren ermöglichen typischerweise eine Aufzeichnung von bis zu vier einzelnen Echos. Alternativ gibt es Scanner, die das komplette Signal mit einer Abtastrate von bis zu 0,5 Nanosekunden digitalisieren. Hier ist es dann möglich, spezielle Auswertungen aufgrund der Wellenform im Postprocessing durchzuführen. (Beraldin et al., 2010, S. 29)

2.2  Positionsbestimmung mittels globalen Navigationssatellitensystemen

Zur Bestimmung der Position des Fluggerätes wird ein Empfänger für globale Navigationssatellitensysteme (global navigation satellite system, GNSS) verwendet. Ein solcher Empfänger kann durch die Laufzeitbestimmung des Signales von verschiedenen Satelliten, zum Beispiel des US-amerikanischen Navstar GPS, seine aktuelle Position bestimmen. Hierzu ist eine freie Sicht zum Himmel notwendig. Je nach Auswertung und Weiterverarbeitung des Signales sind verschiedene Genauigkeiten möglich. Ohne zusätzliche Daten beträgt sie etwa 5 m. Durch die Nutzung von Referenzstationsnetzen wie SAPOS können Genauigkeiten von 1-2 cm in Echtzeit in Bewegung oder bei statischen Dauermessungen von wenigen Millimetern erreicht werden. Es befinden sich pro weltweiten System etwa 30 Satelliten in einer bekannten Umlaufbahn. (Witte & Schmidt, 2006, S. 375)

Durch an Bord befindliche Atomuhren können die Satelliten hochgenaue Zeitstempel und sich wiederholende Codemuster aussenden. Im Fall von Navstar GPS erfolgt die Aussendung aktuell auf drei verschiedenen Frequenzen L1, L2 und L5. Für die öffentliche Nutzung ist nur L1 freigegeben. L2 und L5 sind der militärischen Nutzung vorbehalten. Durch reine Auswertung des ausgesendeten L1-Codes können Genauigkeiten bis 5 m erreicht werden. Für geodätische Anwendungsfälle wird zusätzlich die Phasenmessung benutzt. Hierbei wird nicht nur das dem Funksignal aufmodulierte Codemuster ausgewertet, sondern auch die Phase des Signals. Hierdurch ist es auch möglich, dass verschlüsselte L2-Signal mitzunutzen. (Witte & Schmidt, 2006, S. 10f)

2.3  Inertiale Messeinheit

Bei der inertialen Messeinheit (inertial measurement unit, IMU) handelt es sich um einen Sensor, der die Neigung sowie Drehbewegungen der Sensoreinheit misst. Sie wird benötigt, um bei dem Airborne Laserscanning die genaue Ausrichtung des Laserscanners im Raum zu bestimmen. Daher muss diese auch verdrehsicher mit dem Laserscanner verbunden sein. In Kombination mit den Positionsdaten des GNSS-Modules ermöglicht diese die Rekonstruktion der Flugbewegungen (Trajektorie). Ein weiterer Vorteil der inertialen Messeinheit ist ihre Messfrequenz: Im Gegensatz zum GNSS, dass im Normalfall nur eine Messung pro Sekunde durchführt, kann die IMU bis zu 500 Messungen pro Sekunde ausführen. Sie stützt daher nicht nur die GNSS-Messung, sondern hilft auch die Trajektorie zu interpolieren und somit auch für den Bereich zwischen den GNSS-Messungen genaue Positionen zu bestimmen. (Beraldin et al., 2010, S. 23ff)

Die Messung erfolgt mit mehreren Einzelsensoren: Für die Messung der Beschleunigung in drei Dimensionen sind drei jeweils rechtwinklig zueinander stehende Beschleunigungsmesser verbaut. In der klassischen Bauform ist hierfür jeweils eine Probemasse zwischen zwei Federn gelagert. Durch eine auf die Probemasse wirkende Beschleunigung wird diese zwischen den Federn ausgelenkt. Die Messung der Drehrate erfolgt mittels drei einzelnen Kreiselinstrumenten (Gyroskop) in drei Achsen. Diese basieren auf Kreiseln, welche drehbar gelagert sind. Sie streben dazu, die Ausrichtung ihrer Drehachsen im Raum beizubehalten. Durch Messung der Kräfte kann die Drehrate berechnet werden. Einige inertiale Messeinheiten enthalten auch ein dreidimensionales Magnetometer, mit dem sich die magnetische Nordrichtung dreidimensional feststellen lässt. (Willemsen, 2016, S. 10)

Die Genauigkeit von inertialen Messeinheiten wird in ihrer Messauflösung und in ihrer zeitlichen Richtungsabweichung, dem Drift, angegeben. Die zeitliche Stabilität ist vor allem bei der Inertialnavigation wichtig, bei der die Ortsbestimmung nur auf Grundlage der Messungen der IMU erfolgt.

Hauptsächlich unterschieden werden die inertialen Messeinheiten in klassische, mechanische Systeme, wie sie bereits hier beschrieben wurden, und mikroelektromechanische Systeme, sogenannte MEMS (microelectromechanical systems). Bei den zweitgenannten handelt es sich um stark miniaturisierte Bauteile (beispielsweise Abbildung 2.2), welche zum Beispiel auch in aktuellen Smartphones eingesetzt werden. Diese werden für Zwecke eingesetzt, in denen keine hohen Genauigkeitsanforderungen gestellt werden und der Preis gering gehalten werden soll. Auch zur Stabilisierung der Fluglage von Multikoptern oder Gimbals werden diese Sensoren eingesetzt. (Willemsen, 2016, S. 9f)

Für geodätische Anwendungsfälle werden meist noch mechanische Systeme genutzt, da deren Genauigkeit und ihr Drift geringer sind. Höherpreisige MEMS-Sensoren erreichen jedoch auch bereits gute Genauigkeiten. (iMAR Navigation GmbH, 2015)

2.4  Kombination der Messsysteme

Um die drei eigenständigen Messsysteme kombiniert nutzen zu können, muss die relative Position der Systeme genau bekannt sein und darf sich während des Fluges nicht verändern. Bei dem klassischen Airborne Laserscanning vom Helikopter werden hierfür zum Beispiel eigenständige Module entwickelt, die alle benötigten Systeme verdrehsicher enthalten und an den Kufen des Helikopters montiert werden können. Außerdem müssen alle Systeme synchronisiert werden, damit die Daten später miteinander verarbeitet werden können. Hierfür wird üblicherweise das Sekundensignal des Navigationssatellitensystems (pulse per second, PPS) genutzt. Das GNSS-System sendet dazu zu jeder vollen Sekunde der GNSS-Zeit ein Impuls aus, mit welchem sich die anderen Sensorsysteme synchronisieren können. (Beraldin et al., 2010, S. 23f)

2.5  Bisherige Systeme zur dreidimensionalen Erfassung mittels Multikoptern

Die meisten aktuellen Verfahren zur Erzeugung von 3D-Modellen unter Nutzung von kompakten Multikoptern mit einer Tragkraft von bis zu 5kg, basieren auf photogrammetrischen Verfahren (Acevedo Pardo et al., 2015). Sie erzeugen Bilder, meist unter direkter Georeferenzierung (Ehring et al., 2016, S. 16f), welche im Postprocessing zu Bildverbänden verknüpft werden. Mittels automatischer Bildauswertung werden hieraus 3D-Punktwolken berechnet (Ehring et al., 2016, S. 18f). Nachteil dieses Verfahrens ist es, dass ausreichende Beleuchtung vorhanden sein muss. Es kann somit nur tagsüber geflogen werden, aber auch starke Schatten können das Ergebnis verschlechtern. Für die automatische Erstellung von Punktwolken muss außerdem das Gelände ausreichende Strukturen aufweisen, damit die automatische Verknüpfung der Pixel erfolgen kann.

Laserscanning, als aktiver Sensor, hat hier den Vorteil, dass keine zusätzliche Beleuchtung benötigt wird – der Sensor bringt sein Licht selber mit. Problematisch ist hierbei jedoch die Größe der Systeme. Aus diesem Grund wurden bisher hauptsächlich Systeme mit großen UAVs erprobt und verwendet. Durch die immer weiter fortschreitende Miniaturisierung und die Weiterentwicklung von Laserscannern, zum Beispiel für die Entwicklung von autonomen Fahrzeugen, werden die Scanner auch inzwischen kleiner und leistungsfähiger. (Ehring et al., 2016, S. 19)

3  Technische Realisierung

Im Folgenden wird zunächst auf die verwendeten Sensoren und Geräte und ihre technischen Eigenschaften eingegangen, bevor danach auf die technischen Verbindungen der Komponenten eingegangen wird.

3.1  Verwendete Sensoren und Geräte

3.1.1  Velodyne VLP-16

Um Gewicht zu sparen, wird für die Messung ein miniaturisierter Laserscanner eingesetzt. Einer dieser Kompakt-Laserscanner ist der Velodyne Puck VLP-16 (siehe Abbildung 3.1). Sein Durchmesser beträgt 10,3 cm, seine Höhe 7,3 cm und sein Gewicht 830 g ohne Kabel und Schnittstellenbox. Der VLP-16 hat 16 fest ausgerichteten Messstrahlen, die sich zusätzlich um die Hochachse drehen. Wahrscheinlich handelt es sich um einen Glasfaser-Scanner, Angaben macht der Hersteller hierzu jedoch keine. Seine Messgenauigkeit beträgt laut Datenblatt 3 cm. Gemessen wird im Impulsmessverfahren (siehe Absatz 2.1.1.0.0) mit einem 903nm-Infrarotlaser. (Velodyne Lidar Inc., 2017b)

Der Scanner sendet die Messstrahlen mit einem Zeitabstand von 2,3 $\mu$s aus, gefolgt von einer Nachladezeit von 18,4 $\mu$s, so dass jeder Messstrahl alle 55,3 $\mu$s ausgesendet werden kann (Velodyne Lidar Inc., 2016, S. 16). Es ergibt sich somit eine durchschnittliche Messfrequenz von 289 357 Hz (siehe Gleichung 3.1). Während der Messungen dreht sich der Laserscanner je nach Einstellung über das Webinterface des Scanners mit 5 bis 20 Umdrehungen pro Sekunde (Velodyne Lidar Inc., 2017b). Pro ausgesendeten Strahl können jeweils die stärkste und die letzte Reflexion zurückgegeben werden, so dass über eine halbe Million Punkte pro Sekunde gemessen werden können (siehe Gleichung 3.1). Die Daten werden anschließend über den Netzwerkanschluss gestreamt (siehe auch Abschnitt 4.2). Außerdem verfügt der Scanner über einen Anschluss für ein GNSS-Modul des Typs Garmin GPS 18x LVC. Auch andere GNSS-Module sind verwendbar, so dass im Weiteren versucht wurde, ein kostengünstiges uBlox-GNSS-Modul zu nutzen (siehe Abschnitt 3.4). Durch die Nutzung eines GNSS-Modules am Scanner ist es möglich, die Daten mit einem hochgenauen Zeitstempel zu versehen und die Messungen des Scanners so mit den Daten aus der inertialen Messeinheit zu verknüpfen.

3.1.2  Inertiale Messeinheit und GNSS-Empfänger iMAR iNAT-M200-FLAT

Als inertiale Messeinheit wird das auf Abbildung 3.2 zu sehende Sensorsystem des Typs iMAR iNAT-M200-FLAT verwendet. Hierbei handelt es sich um ein hochgenaues MEMS-System. Durch die Verwendung von mikroelektromechanischen Bauteilen wiegt der Sensor inklusive Gehäuse nur 550 g. Dieser kann bis zu 500 Messungen pro Sekunde durchführen. Der Drift pro Stunde liegt unter 0,5${\circ }^{}$. (iMAR Navigation GmbH, 2015)

Außerdem verfügt die verwendete Einheit über zwei differentielle Satellitennavigationsempfänger (GNSS-Module, siehe Abbildung 3.3). Durch Nutzung einer zusätzlichen GNSS-Basisstation oder auch eines entsprechenden Korrekturdienstes können diese eine Positionsgenauigkeit von etwa 2 cm in Echtzeit erreichen (iMAR Navigation GmbH, 2015). Durch Postprocessing lässt sich diese sogar noch steigern. Durch die Verwendung von zwei Empfängern, die an jeweils einem Ausleger befestigt sind (siehe Bild Abbildung 3.3), kann auch die Orientierung der IMU bestimmt werden. Hierdurch kann die durch Störungen, wie den Motoren des Multikopters, möglicherweise ungenaue Messung der magnetischen Nordrichtung kontrolliert werden. Außerdem kann die Positionssicherheit durch Mittelung der beiden Positionen erhöht werden und auch der Drift durch die Daten eliminiert werden.

Im Postprocessing kann aus den Daten der inertialen Messeinheit zusammen mit denen der GNSS-Module und GNSS-Korrekturdaten eine genaue Flugbahn des Multikopters berechnet werden. Die Daten der inertialen Messeinheit werden hierbei regelmäßig durch die Daten der GNSS-Module gestützt. Wilken (2017) untersuchte in seiner Bachelorthesis die Genauigkeit des Empfängers im Vergleich zu einem geodätischen GNSS-Empfänger. Seine Messungen bestätigten die angegebenen Genauigkeiten. Jedoch traten Probleme bei der Nutzung der zweiten GNSS-Antenne auf, so dass nicht die Position der IMU zwischen den beiden Antennen ermittelt wurde, sondern die Position der primären Antenne. Das GNSS des IMU-Modules ist daher aktuell noch nicht voll einsetzbar, da dieses Problem zuvor gelöst werden muss.

3.1.3  Raspberry Pi 3 Typ B

Die Verarbeitung der Daten soll mit einem Raspberry Pi 3 (siehe Abbildung 3.4) erfolgen. Es handelt sich hierbei um einen von der Raspberry Pi Foundation entwickelten Einplatinencomputer. Die Stiftung gründete sich 2006, um einen erschwinglichen Computer zu entwickeln, an dem Schüler direkt Hardware- und Elektronikprojekte entwickeln können. Die erste Version des Raspberry Pi kam im Februar 2012 auf den Markt. Dieser verfügte über einen 700 MHz Ein-Kern-Prozessor und 256 MB Arbeitsspeicher. Das verwendete dritte Modell verfügt über einen Vier-Kern-Prozessor mit 1,2 GHz und 1 GB Arbeitsspeicher. Bisher wurden alle Versionen zusammen über elf Millionen Mal verkauft (Stand November 2016). (Möcker, 2017)

Alle Modelle der Raspberry Pi Serie basieren auf Ein-Chip-Systemen des Halbleiterherstellers Broadcom. In diesem Chip sind die wichtigsten Bauteile des Systems integriert wie zum Beispiel ein ARM-Prozessor, eine Grafikeinheit sowie verschiedene andere Komponenten. Die so gering gehaltene Anzahl an einzelnen Bauelementen bei dem Raspberry Pi ermöglichen den geringen Preis – ein Ziel der Raspberry Pi Foundation.

Vorteilhaft bei der Nutzung des Raspberry Pi zur Datenverarbeitung sind vor allem seine verschiedensten Schnittstellen zur Datenein- und ausgabe (RS Components Ltd., 2015):

• 4 USB 2.0 Host-Anschlüsse

• 100 Mbit-Netzwerkschnittstelle (RJ45)

• Bluetooth- und WLAN

• 27 GPIO-Ports, nutzbar als (Schnabel, 2017b)

  • Digitale Pins

  • Serielle Schnittstelle

  • I2C-Schnittstelle

  • SPI-Schnittstelle

• Stromversorgung 3,3 V und 5 V

• Micro-USB-Anschluss zur eigenen Stromversorgung (5 V)

• microSD-Steckplatz

• verschiedene Video- und Audioausgänge

Praktisch für die Nutzung am Multikopter ist außerdem seine geringe Größe und sein relativ geringer Stromverbrauch von maximal 12,5 Watt (RS Components Ltd., 2015). Im Betrieb ohne weitere Peripherie außer einem GNSS-Chip wird dieser Stromverbrauch bei weitem nicht erreicht, hier wurden durchschnittlich nur 2,5 Watt gemessen.

Alternativ zum Raspberry Pi kämen zur Datenverarbeitung an Bord des Multikopters auch Mikrokontroller-Boards wie die der Arduino-Serie in Frage. Vorteile eines Arduinos wären vor allem der geringere Stromverbrauch und die Echt-Zeitfähigkeit. Jedoch ist die Steuerung der Datenaufnahme über die Netzwerkschnittstelle und die Speicherung deutlich komplizierter und die Hardware nicht so leistungsfähig. Bei dem Raspberry Pi übernimmt das Betriebssystem die grundlegenden Steuerungen, so dass nur noch die Daten selbst verarbeitet werden müssen. Außerdem bietet dieser mit den fest verbauten Schnittstellen auch die komplette benötigte Hardware, die so nicht einzeln zusammengestellt beziehungsweise gebaut werden muss.

3.1.4  Multikopter Copterproject CineStar 6HL

Bei einem Multikopter handelt es sich um ein Fluggerät mit drei oder mehr Rotoren. Weit verbreitetet sind vor allem Quadrokopter mit vier oder Hexakopter mit sechs Rotoren. Multikopter wurden ursprünglich für Militär- und Polizeizwecke eingesetzt, inzwischen sind diese aber auch vermehrt in kleineren Ausführungen in Privatbesitz zum Beispiel für Videoaufnahmen zu finden (Heise Online, 2017). Angetrieben werden die handelsüblichen Modelle, welche eine Flugdauer von bis zu 30 Minuten und eine Tragkraft von bis zu 5 kg aufweisen, mit Lithium-Polymer-Akkumulatoren (LiPo-Akkus). Die Anzahl und die maximale Umdrehung der Rotoren bestimmt die Schubkraft und somit auch die Tragkraft des Multikopters. Im Normalfall besitzen diese eine gerade Anzahl von Rotoren. Das auf das Traggestell wirkende Drehmoment hebt sich so auf. Hier liegt auch der Vorteil der Bauform gegenüber einem Hubschrauber, bei welchem mit einem Heckrotor dem Drehmoment um die Hochachse entgegengewirkt werden muss. Die einzelnen Motoren und Propeller werden kreuzweise angeordnet, so dass eine Drehzahländerung eines Propellerpaares jeweils zur Steuerung ausreicht. Vorteil eines Multikopters im Gegensatz zu einem Modellflugzeug ist es außerdem, dass dieser senkrecht starten und auch zum Beispiel für die Aufnahme von Bildern auf der Stelle stehen bleiben kann. Nachteil ist der höhere Energieverbrauch, so dass Modellflugzeuge bei gleicher Akkukapazität deutlich länger in der Luft bleiben können. (Bachfeld, 2013)

Für dieses Projekt soll der Multikopter den Laserscanner, die IMU, das Gimbal, die Stromversorgung, die Datenverarbeitung und -speicherung im Betrieb tragen können. Bei der Systementwicklung des Multikopters muss daher darauf geachtet werden, dass das Gewicht möglichst gering bleibt. Dennoch müssen die angehängten Messeinrichtungen auch gegebenenfalls für härtere Landungen ausgelegt sein. Der verwendete Hexakopter (siehe Abbildung 3.5) hat eine Tragkraft von maximal 5 kg und eine Flugdauer von bis zu 20 Minuten (Schulz, 2016).

3.1.5  Gimbal Freefly MöVI M5

Um die Messgeräte während des Fluges des Multikopters zu stabilisieren und zu verhindern, dass sich jede Neigung durch die Flugsteuerung an den Laserscanner überträgt, wird ein sogenanntes Gimbal verwendet. Durch einen Regelkreis aus Motoren und einer inertialen Messeinheit (siehe auch Abschnitt 2.3) werden Neigungen und Drehungen in Echtzeit ausgeglichen. Außerdem ermöglichen es die meisten Gimbals, die Messtechnik unabhängig vom Multikopter auszurichten – dies ist zum Beispiel bei der Luftbildaufnahme wichtig.

Für das Projekt wird ein Gimbal des Herstellers Freefly verwendet. Dieses wurde zur Stabilisierung von Aufnahmen mit digitalen Spiegelreflexkameras entwickelt und hat eine Tragkraft von 2,3 Kilogramm. Außer dem erwähnten Beschleunigungsmesser verwendet diese auch GNSS um das Driften der integrierten IMU zu vermindern. (Freefly Systems, 2017)

3.2  Stromversorgung

Die Stromversorgung der Mess- und Verarbeitungstechnik soll mittels Lithium-Ionen-Zellen erfolgen. Der Raspberry Pi benötigt hierbei eine stabilisierte Spannung. Eine fehlerhafte Versorgung kann zu Systeminstabilitäten führen und so im schlimmsten Fall die Datenaufzeichnung komplett verhindern. Auf den Aufbau einer solchen Versorgung wird hier verzichtet, sondern nur die Anforderungen an die Energiequelle erläutert.

Tabelle 3.1 listet die verschiedenen Module und die jeweils benötigte Energieversorgung auf. Der Multikopter mit der Gimbal verfügt über eine eigene Versorgung und muss daher nicht weiter beachtet werden. Außerdem hat hier eine eigene Akkukapazität auch Vorteile – bei einem zu hohen Verbrauch der Sensortechnik bleibt der Multikopter durch seine eigenständige Akku-Überwachung immer noch flugfähig um sicher landen zu können.

Für eine geplante Flugdauer von 30 Minuten wird bei einem angenommenen Wirkungsgrad von 90 % eine Akkukapazität von mindestens 16 Wh (siehe Gleichung 3.2) benötigt. Es wird eine Spannungsversorgung von 5 V und 12 V benötigt. Gegebenenfalls sind hierfür auch zwei komplett unabhängige Spannungsquellen zu nutzen.

3.3  Verbindung des Raspberry Pi an den Laserscanner

Der Laserscanner wird mit einem RJ45-Kabel an der Netzwerkschnittstelle des Raspberry Pi angeschlossen. Die inertiale Messeinheit zeichnet die Daten selbstständig auf, kann aber auch mittels der als serieller Schnittstelle nutzbaren GPIO-Pins an den Raspberry Pi angeschlossen werden. Außerdem kann an diesen Port auch ein GNSS-Modul angeschlossen werden. Dieses GNSS-Modul wird im Folgenden benutzt, um dem Raspberry Pi und dem Laserscanner eine genaue Uhrzeit zu liefern, welche für die Verarbeitung der Daten benötigt wird. Alternativ kann auch ein nur an den Laserscanner angeschlossenes GNSS-Modul sein Zeitstempel per Netzwerk an den Raspberry Pi liefern.

3.4  Verbindung des GNSS-Modules an den Laserscanner

Für die Versorgung des Laserscanners mit einem GNSS-Signal zur Synchronisierung wurde ein zusätzliches GNSS-Modul vom Typ uBlox NEO-6M mit PPS-Signal ausgewählt (ähnlich dem auf Abbildung 3.6), da dieses kleiner und leichter ist, als die entsprechenden Adapterkabel der inertialen Messeinheit um dessen Signal nutzen zu können.

Die Übertragung der Daten des GNSS-Modules zum Laserscanner erfolgt per serieller Schnittstelle über einen acht poligen Platinensteckverbinder. Da dieser Stecker jedoch unpraktisch war, wurde zusätzlich eine 3,5 mm Klinkenbuchse an der Schnittstellenbox des Laserscanners montiert. Bei dem vom Laserscanner benötigten Übertragungsprotokoll handelt es sich um das standardisierte NMEA-Protokoll, welches mit einer Datenrate von $9600\frac{bit}{s}$ und einer Signalspannung zwischen 3 und 15 V übertragen wird. Der direkte Anschluss des uBlox-GNSS-Modules brachte dennoch zunächst keinen Erfolg. Oszilloskop-ähnliche Messungen mit einem Arduino Mega 2560 (siehe Abbildung 3.7) zeigten, dass das Signal des verwendeten GNSS-Modules nicht dem im Datenblatt von Velodyne Lidar Inc. (2017a, S. 3) geforderten entsprach. Es zeigte sich, dass das Signal gedreht werden musste, da die Definition der Signalspannung verschieden war: Der Laserscanner benötigte ein Signal, bei dem Logisch 1 mit einer Spannung von über 3 V (Velodyne Lidar Inc., 2017a, S. 3) entspricht (HIGH), bei dem GNSS-Modul entsprach die höhere Spannung Logisch 0.

Um das Signal zu drehen wurde ein integrierter Schaltkreis 74HC04 verwendet. Hierbei handelt es sich um einen Logikkonverter, der die HIGH- und LOW-Signale (Signal gegen Masse) tauscht. Der Laserscanner sieht eine Versorgung des GNSS-Modul mit 5 V vor, während das eingesetzte Modul nur eine Spannung von 3,3 V benötigt. Es wurde daher ein Spannungsregler verbaut, der die Spannung auf 3,3 V begrenzt. Zur weiteren Stabilisierung wurden Kondensatoren genutzt. Der Logikkonverter dient hier durch die Versorgung mit 5 V auch als Pegelwandler. Die genaue Schaltung ist Abbildung 3.8 zu entnehmen.

3.5  Steuerung im Betrieb

Der Betrieb des Raspberry Pi erfolgt ohne Tastatur und Bildschirm. Daher ist es notwendig, eine alternative Benutzerschnittstelle zu implementieren. Ein großer Steuerbedarf ist nicht gegeben, so dass wenige Tasten zum Stoppen der Datenaufzeichnung und zum Herunterfahren des Raspberry Pi ausreichend sind. Um auch eine Steuermöglichkeit zu implementieren, die im Flug genutzt werden kann, soll ein WLAN-Access-Point und ein simpler Webserver auf dem Raspberry Pi implementiert werden, der den Zugriff zum Beispiel über ein Smartphone oder Laptop ermöglicht.

Abbildung 3.9 zeigt den Schaltplan zum Entwurf des Steuermodules. Dieses bietet mit drei Leuchtdioden und 2 Tastern die Möglichkeit, im Skript später einfache Anzeigen und Eingaben zu realisieren. Hierfür wurde eine Erweiterung auf Basis des GPIO-Portes des Raspberry Pi aufgebaut. Die zwei Taster sind über die beiden GPIO-Pins 18 und 25 erreichbar. Ohne Betätigung werden die Eingänge über die Pull-Up-Widerstände R4 und R6 auf ein HIGH-Level gezogen. Durch Drücken des Tasters wird die Spannung über die Widerstände R5 und R7 auf ein LOW-Level gezogen, welches durch das Python-Skript zur Laufzeit ausgelesen werden kann. Die Widerstände R5 und R7 dienen außerdem zur Strombegrenzung und als Sicherheit, falls die GPIO-Pins falsch geschaltet werden. In der weiteren Optimierung der Schaltung wurden die externen Pull-Up-Widerstände (R4 und R6) durch die internen, softwaretechnisch schaltbaren Pull-Up-Widerstände des Raspberry Pi ersetzt. Dies ermöglicht auch die Nutzung des Raspberry Pi ohne angestecktes Steuermodul. Ansonsten könnten im Betrieb ohne Steuermodul auftretende Spannungsschwankungen fehlerhafterweise zu einer Erkennung als Tastendruck führen. Außerdem wurde die Funktion zum Starten und Stoppen auf zwei Taster verteilt, so dass hierfür ein dritter Taster verbaut wurde.

Die drei Leuchtdioden wurden mit jeweils einem 150 $\mathrm{\Omega }$ Vorwiderstand direkt zwischen einem GPIO-Pin und Masse eingebaut. Durch Ansteuerung der GPIO-Pins lassen sich diese an- und abschalten. Außer zum Schutz und Betrieb der LEDs verhindern die Vorwiderstände auch eine zu hohe Stromaufnahme aus den GPIO-Pins. Die genaue Belastbarkeit der Pins ist nicht dokumentiert, jedoch wird meist von einem Wert um 10 mA bei 3,3 V gesprochen (zum Beispiel Schnabel, 2017b). Alternativ, bei Nutzung leistungsstärkerer LEDs könnten diese auch unter Nutzung eines Transistors geschaltet werden. Diese ermöglichen es mit einem geringen Steuerungsstrom höhere Ströme zu schalten.

3.6  Platinenentwurf und -realisierung

Nach dem Entwurf und Test der beiden Schaltungen aus Abbildung 3.8 und Abbildung 3.9 auf einem lötfreien Steckbrett, sollten diese Schaltungen zum späteren Einsatz an Bord des Multikopters als Platine mit verlöteten Bauteilen erstellt werden. Vorteil der gelöteten Schaltung ist ihre höhere Widerstandsfähigkeit gegen Vibrationen und Korrosion. Durch die Vibrationen im Flug könnten sich sonst die gesteckten Bauteile lösen und im schlimmsten Fall zum Kurzschluss und somit zur Zerstörung führen. Auch können die Kontakte zwischen den Federklemmen und den Bauteilen bei dem Betrieb außerhalb von Gebäuden durch Luftfeuchtigkeit korrodieren und somit der Kontaktwiderstand erhöht werden, was zu Störungen führen kann.

Für den Prototyp sollte die Schaltung von Hand aufgebaut und verlötet werden. Erst in der zukünftigen Entwicklung, wenn die Schaltung ausreichend erprobt wurde, könnte es sinnvoll sein, eine Platine ätzen zu lassen. Als Platine kommen daher vorerst nur vorgefertigte Layouts in Frage:

• Lochrasterplatinen (Platine mit einzelnen Lötpunkten)

• Streifenrasterplatine (Lötpunkte sind in Streifen verbunden)

• Punktstreifenrasterplatine (Streifenrasterplatine, bei denen die Streifen regelmäßig, zum Beispiel alle 4 Lötpunkte, unterbrochen sind)

• spezielle Aufsteckplatinen für den Raspberry Pi

Da nur wenige Bauteile benötigt wurden, wurde eine Streifenrasterplatine gewählt. Bei einer solchen Platine sind alle Kontakte in einer Reihe mit einer Leiterbahn verbunden. Falls keine Verbindung gewünscht ist, kann diese Leiterbahn mit einem Messer oder ähnlichem unterbrochen werden. Da das Unterbrechen der Leiterbahn jedoch zeitaufwändig und fehlerträchtig ist – beispielsweise durch nicht vollständig getrennte Leiterbahnen – sollten diese bei dem Layouten der Platine möglichst vermieden werden. Auch sollten möglichst viele der benötigten Verbindungen durch die Leiterbahnen erfolgen und möglichst wenige Drahtbrücken verwendet werden, die diese Leiterbahnreihen verbinden. Diese würden ansonsten zusätzlichen Lötaufwand erfordern. Das endgültige Layout der Platine ist der Abbildung 3.10 zu entnehmen. Die fertige Platine ist auf der Abbildung 3.11 zu sehen.

Bei dem Routing wurden noch einige Teile der Schaltung optimiert und versucht einige Bauteile einzusparen. Es wurde zum Beispiel die Stromversorgung des Raspberry Pi für den integrierten Schaltkreis und das GNSS-Modul verwendet, anstatt hierfür einen zusätzlichen Spannungswandler zu verwenden. Die Platinengröße wurde so gewählt, dass die Platine direkt auf den Raspberry Pi 2 oder 3 aufgesteckt werden kann. Der endgültige Schaltplan ist Abbildung 3.12 zu entnehmen. Für die Taster wurden hier die internen Pull-Up-Widerstände genutzt, so dass Widerstände eingespart werden konnten. Außerdem wurde der Datensendeport (Tx) vom GNSS-Modul an die serielle Schnittstelle des Raspberry Pi angeschlossen, so dass der Raspberry Pi nun auch ohne den Umweg über den Laserscanner die Daten vom GNSS-Modul empfangen kann. Es wurde Platz für weitere LEDs oder Taster freigelassen.

4  Theoretische Datenverarbeitung

4.1  Verwendete Programmiersprachen

Python Zur Realisierung der Programmierung wurde die Skriptsprache Python ausgewählt. Python bietet den Vorteil vergleichsweise kurzen und gut lesbaren Programmierstil zu fördern. Hierfür werden unter anderem nicht Klammern zur Bildung von Blöcken genutzt, sondern Texteinrückungen verpflichtend eingesetzt (Theis, 2011, S. 13f). Die Struktur des Programms ist so schnell erfassbar. Außerdem ist es nicht notwendig, den Quellcode zu kompilieren. Dieser wird vom Interpreter direkt ausgeführt. Dies ermöglicht kurze Entwicklungszyklen ohne (zeit-)aufwändiges Kompilieren. Änderungen und Anpassungen können schnell durchgeführt werden. Außerdem sind die Skripte größtenteils plattformunabhängig.

Python wurde in seiner ersten Version 1991 von Guido van Rossum veröffentlicht. Sein Ziel war es, eine einfach zu erlernende Programmiersprache zu entwickeln, die der Nachfolger der Sprache ABC werden sollte. Außerdem sollte die Sprache leicht erweiterbar sein und schon von Haus aus eine umfangreiche Standardbibliothek bieten. Python bietet mehrere Programmierparadigmen an, so dass je nach Aufgabe objektorientiert oder strukturiert programmiert werden kann (Theis, 2011, S. 14).

Die aktuelle Version von Python (Oktober 2017) ist die Version 3.6. Das Skript wurde unter Verwendung dieser Version entwickelt. Da sich viele Funktionen von der Version 2 zur 3 geändert haben, wurde auf die zuerst geplante Kompatibilität zu Python 2 verzichtet. Um Teile des Quellcodes als Python-Module auch in andere Skripte einfach einbinden zu können, aber auch den Quelltext übersichtlich zu halten, wurde der objektorientierte Programmierstil gewählt.

C++ Ein großer Nachteil von Python ist die Ausführungsgeschwindigkeit. Daher wurden einzelne Teile des Quelltextes im Verlauf der Entwicklung in C++ umgeschrieben. Bei C++ handelt es sich um eine objektorientierte Erweiterung der Programmiersprache C. C wurde 1972 von Dennis Ritchie entwickelt. Anfang der 1980er Jahre erweiterte Bjarne Stroustrup C zu C++. C++ hat eine höhere Ausführungsgeschwindigkeit, da es hardwarenaher ist als Python, welches eine Laufzeitumgebung nutzt. (Küveler & Schwoch, 2017, S. 4f)

4.2  Datenlieferung des Laserscanners

Der Laserscanner Velodyne VLP-16 liefert seine Daten als UDP-Netzwerkpakete in einem proprietären, binären Datenformat. Diese Daten sind nicht direkt lesbar, sondern müssen vor einer weiteren Nutzung aufbereitet und umgeformt werden. Dies soll mittels des in dieser Arbeit entwickelten Skriptes durchgeführt werden.

Ein Datenpaket (siehe Tabelle 4.1, Beispiel im Anhang D.1) besteht jeweils aus einem Header von 42 Bytes, gefolgt von 12 Datenblöcken mit jeweils 32 Messungen, abgeschlossen von 4 Bytes, die den Zeitstempel angeben und 2 Bytes, die den eingestellten Scan-Modus zurückliefern. Jeder Datenblock enthält die aktuelle horizontale Ausrichtung des rotierenden Lasers und darauf folgend die Messwerte von zwei Messungen der 16 Laserstrahlen. Die genaue Horizontalrichtung zum Zeitpunkt der Messung muss aus den Horizontalrichtungen von zwei auf einander folgenden Messungen interpoliert werden.

Der Laserscanner sendet bei der Einstellung Dual Return, also der Rückgabe vom stärksten und letzten Echos pro Messung, bis zu 1508 Pakete dieser Form pro Sekunde (Velodyne Lidar Inc., 2016, S. 49). Die Ausgangsdaten werden, bei einer Paketgröße von 1248 Bytes mit einer Datenrate von 1,8 MB/s empfangen (siehe Gleichung 4.1). Hierbei werden fast 600 000 Messwerte pro Sekunde übertragen (siehe Gleichung 4.2).

4.3  Geplantes Datenmodell

Die Daten des Laserscanners sollen in einer einfach lesbaren Textdatei (siehe Anhang D.2) abgelegt werden. In der Nachbereitung sollen die Daten aus dieser Textdatei mit den Daten der inertialen Messeinheit und des GNSS-Empfängers verknüpft werden, um so die Daten georeferenzieren zu können. Als Verknüpfung bietet sich der Zeitstempel an. Die inertiale Messeinheit und der Laserscanner können die Zeitdaten aus dem GNSS-Signal verwenden, wodurch hochgenaue Zeitstempel möglich sind. Die Zeitinformation bildet also einen wichtigen Schlüssel in den Daten. Als einfaches Textformat wurden durch Tabulator getrennte Daten, jeweils eine Zeile je Messung, gewählt. Folgende Daten sind in dieser Reihenfolge enthalten:

• Zeitstempel in Mikrosekunden

• Richtung der Messung in der Rotationsebene in Grad

• Höhenwinkel zur Rotationsebene in Grad

• Gemessene Entfernung in Metern

• Reflektionsgrad auf einer Skala von 0 bis 255

Problematisch ist bei diesem Datenmodell jedoch die benötigte Datenrate. Eine Datenzeile erfordert 29 Bytes und somit wird bei über einer halben Million Messungen pro Sekunde (siehe Gleichung 4.2) eine Datenschreibrate von mindestens 16 MB/s benötigt (siehe Gleichung 4.3). Da das Schreiben nicht dauerhaft erfolgt, sollte die Datenrate bevorzugt deutlich höher sein.

Erste Tests ergaben, dass diese Verarbeitungsgeschwindigkeit nicht mit dem Raspberry Pi erreicht werden konnte. Außerdem benötigen die Daten sehr viel Speicher. Daher wurde sich später für eine Hybridlösung entschieden (siehe Kapitel 5).

4.4  Weiterverarbeitung der Daten zu Koordinaten

Die als Text gespeicherten Rohdaten sollen im Rahmen einer weiterführenden Arbeit zu Koordinaten umgewandelt werden. Für diese Umwandlung werden die Daten des GNSS-Empfängers und der IMU verwendet, um eine Trajektorie zu berechnen. Aus der Trajektorie kann dann die Position und die Ausrichtung des Laserscaners für jeden Messzeitpunkt bestimmt werden und auf die Messdaten angewandt werden, um hieraus eine Koordinate im übergeordneten System zu bestimmen.

Bei der Berechnung ist jedoch zu beachten, dass der Ursprungsort der Entfernungsmessung zwar in der Drehachse des Laserscanners liegt, jedoch der Schnittpunkt der ausgesendeten Strahlen etwa 40 mm in Strahlrichtung verschoben ist (siehe Abbildung 4.1). Bei der Streckenberechnung ist diese Strecke mit enthalten, jedoch kann zur Berechnung der Z-Komponente der lokalen Koordinaten nicht einfach der Höhenwinkel und die gemessene Strecke verwendet werden. Die lokalen Koordinaten berechnen sich somit nach der Gleichung 4.4.

4.5  Anforderungen an das Skript

Aus den technischen Vorgaben ergeben sich dann folgende Funktionen, die das Skript aufweisen muss:

• Rohdaten vom Scanner abrufen

• Zeit vom GNSS-Modul abrufen

• Steuerungsmöglichkeit mittels Hard- und Software

• Umwandlung in eigenes Datenmodell

Der Ablauf ist oft abhängig vom Fortschritt anderer Schritte und Voraussetzungen. Daher wurden die benötigten, einzelnen Schritte vorerst als grober Ablaufplan skizziert. So hat der Raspberry Pi keinen eigenen Zeitgeber. Um die Dateien aber mit dem korrekten Zeitstempel zu versehen, ist daher eine aktuelle Uhrzeit notwendig – diese liefert das GNSS-Modul, sofern ein GNSS-Fix besteht. Es muss also, vor dem Erzeugen der Dateien, auf ein gültiges GNSS-Signal gewartet werden. Der endgültige, vereinfachte Ablaufplan ist der Abbildung 4.2 zu entnehmen.

5  Entwicklung des Skriptes

Die Entwicklung des Skriptes bzw. des Programmes erfolgte iterativ-inkrementell. Bei diesem Vorgehensmodell, welches stark mit der agilen Entwicklung verknüpft ist, wird anfangs nur ein grobes Anforderungsprofil (siehe Abschnitt 4.5) festgelegt. Es werden regelmäßig Prototypen erstellt und geprüft. Bei dieser Prüfung werden neue Anforderungen gesammelt beziehungsweise bestehende konkretisiert. So ist am Anfang der Entwicklung noch nicht klar, wie das Produkt am Ende aussehen wird und welchen Funktionsumfang dieses hat. Vorteil dieser Entwicklung ist es, dass schnell funktionsfähige Prototypen ermöglicht werden und auch durch den Auftraggeber, in diesem Fall die Betreuer, ständig Einfluss auf die Funktion und die Bedienung der Software möglich ist. (Kleuker, 2013, S. 33f)

Zur Unterstützung der Programmierung wurden vor allem die Lehrbücher Einstieg in Python (Theis, 2011), Python 3 Object-oriented Programming (Phillips, 2015), Learning Flask Framework (Copperwaite, 2015) und C/C++ für Studium und Beruf (Küveler & Schwoch, 2017) verwendet.

5.1  Klassenentwurf

Da das Skript objektorientiert programmiert werden soll, wurden zunächst mit Hilfe der anfangs bekannten Anforderungen und dem Ablaufplanes aus Abbildung 4.2 die benötigten, grundlegenden Klassen entworfen. Durch die Erweiterungen und die übliche Refaktorisierung – der ständigen Optimierung des Quellcodes in seiner Lesbarkeit und Geschwindigkeit (Kleuker, 2013, S. 255) – erweiterte sich dieses Modell zu den endgültigen Klassen der Abbildung 5.1. Auf die Funktionen der einzelnen Klassen wird im Abschnitt 5.5 eingegangen.

5.2  Evaluation einzelner Methoden

Um eine einfache Fehlersuche zu ermöglichen, wurden die grundlegenden Funktionen in einzelnen Skripten entwickelt und geprüft. Diese kleineren Skripte haben den Vorteil, dass Fehler schneller eingegrenzt und auch schon früh konzeptionelle Fehler entdeckt werden können. In diesem Schritt wurde bemerkt, dass die Geschwindigkeit der Datenverarbeitung ein großes Problem darstellt.

Datenempfang Die Verbindung zum Laserscanner mittels Python-Socket funktionierte ohne weitere Probleme. Die binären Daten konnten zeitgleich abgespeichert werden.

Datentransformation Die Daten sollten zuerst direkt in das in Abschnitt 4.3 vorgestellte Datenmodell umgeformt werden. Hierzu sollte der Empfang der Daten direkt eine Umformmethode starten. Die Versuche erfolgten zunächst mit dem im vorherigen Test aufgezeichneten Daten. Schon hier zeigte sich, dass die Umwandlung der aufgezeichneten Daten etwa das Fünffache der Mess- und Aufzeichnungszeit beanspruchte. Wie erwartet, brachte auch das direkte Einlesen der Daten vom Scanner keinen Erfolg. Es folgte ein Überlauf des Netzwerk-Buffers und somit der Verlust von Messdaten. Grund hierfür war hauptsächlich die benötigte Prozessorzeit. Die Nutzung einer schnelleren Datenspeicherung auf einer Solid-State-Disk mit einer Schreibrate von bis zu 300 MB/Sekunde änderte nichts an der Geschwindigkeit des Skriptes. Auch das Erzeugen eines neuen Threads für jeden empfangenen Datensatz war nicht erfolgsversprechend, da bis zu 1500 Threads pro Sekunde hierdurch gestartet wurden und das gesamte System überlastet wurde. Die Umformung musste daher von dem Datenempfang entkoppelt werden und das Skript für die Nutzung von Mehrkernprozessoren optimiert werden. Threads in Python laufen dennoch in einem Prozess und somit nur auf einem Prozessor. Es wurde das in Abschnitt 5.3 vorgestellte Multikern-Konzept erarbeitet.

Hardware-Steuerung Ein Tastendruck auf dem Steuerungsmodul aus Abschnitt 3.5 sollte den Raspberry Pi zum Beispiel herunterfahren. Auch dieses Skript wurde getestet. Ein Problem hierbei war es, dass das Skript Administratorrechte (root) benötigte, um den Rechner herunterfahren zu können. Hierfür wurde jedoch eine Lösung gefunden, indem dem Nutzer pi die entsprechenden Rechte zum Herunterfahren gegeben wurden (siehe Abschnitt 6.2). Eher zufällig zeigte sich aber noch ein anderes Problem: Sofern das Skript automatisch mit dem Start des Raspberry Pi gestartet wurde und das Steuermodul nicht angeschlossen war, fuhr der Raspberry Pi automatisch nach wenigen Sekunden Betrieb herunter. Da mit dem fehlenden Modul auch die Pull-Up-Widerstände fehlten, war der GPIO-Pin auf einem nicht definierten Zustand. Es kam dazu, dass dieser zufällig auf einem LOW-Niveau war, welches als Drücken des Tasters interpretiert wurde und den Herunterfahrprozess startete. Um dieses Problem zu unterdrücken, wurde dem Skript zuerst eine vorherige Abfrage hinzugefügt, die bei dem Start überprüft, ob die beiden Taster sich auf einem HIGH-Niveau befinden, dass durch die beiden angeschlossenen Pull-Up-Widerstände erreicht wird. Falls dieses nicht der Fall ist, beendet sich die Hardwaresteuerung selbstständig. Im weiteren Verlauf der Entwicklung wurden die internen Pull-Up-Widerstände des Raspberry Pi verwendet. Somit wurde diese Abfrage überflüssig.

5.3  Multikern-Verarbeitung der Daten

Da bei der Evaluation der einzelnen Methoden herausgefunden wurde, dass die Verarbeitungsgeschwindigkeit des Raspberry Pi für eine sofortige Transformation der Daten nach deren Eingang zu langsam ist, wurde ein Konzept erarbeitet, den hierdurch auftretenden Messdatenverlust zu unterdrücken.

Der Verarbeitung musste ein weiterer Buffer vorgeschaltet werden. Das plötzliche Abschalten des Raspberry Pi, zum Beispiel durch einen Verlust der Energieversorgung, sollte jedoch nicht zu Datenverlusten führen. Es konnte daher nicht die in Python integrierten Funktionen zur Datenzwischenspeicherung verwendet werden – diese nutzen zur Zwischenspeicherung den Arbeitsspeicher, der durch Stromverlust gelöscht wird. Das dauerhafte Schreiben auf die Festplatte – im Fall des Raspberry Pi einer microSD-Speicherkarte – führt aber zur weiteren Verzögerung. Es wurde daher eine Hybridlösung erarbeitet.

Die Arbeit wird nun auf mehrere Prozesse verteilt:

• Start des Skriptes und Gesamtsteuerung in einem Prozess mit mittlerer Priorität (Klasse VdAutoStart, mit Threads für die Weboberfläche (Methode startWeb() in der Klasse VdAutoStart) und Hardwaresteuerung (Klasse VdHardware)

• Sammeln der Daten in einem Prozess mit höchster Priorität (Klasse VdBuffer)

• Umformen der Daten durch mehrere Prozesse je nach Prozessorkernanzahl mit erhöhter Priorität (Klasse VdTransformer)

Die Daten werden nun zuerst für wenige Sekunden im Arbeitsspeicher gesammelt. Sobald eine in der Konfiguration festgelegte Anzahl von Datensätzen zwischengespeichert wurde, werden diese im Dateisystem als binäre Datei abgelegt und der Dateiname in einer Warteschlange aus dem multiprocessing-Modul von Python (Klasse Queue) abgelegt. Die Prozesse zum Umformen der Daten fragen diese Warteschlange nun ab, verarbeiten jeweils eine binäre Datei und hängen die Ergebnisse an eine Ergebnis-Textdatei an. Die Dateinamen der binären Dateien, dessen Bearbeitung begonnen wurde, werden aus der Warteschlange entfernt. Nach dem Schreiben der umgeformten Daten werden die binären Dateien aus dem Dateisystem entfernt (abschaltbar). Damit die Transformationsprozesse beim Schreiben nicht aufeinander warten müssen, schreibt jeder Prozess in eine andere Ergebnisdatei. Diese können nach der Messung einfach zusammengefügt werden. Falls zum Beispiel die Stromversorgung unterbrochen wird, sind nun nur die Daten der letzten Sekunden verloren. Ältere Daten sind auch trotz Spannungsverlust als binäre Daten oder als Textdatei gespeichert. Durch ein Konvertierungsskript (siehe Anhang A.16) ist es im Nachhinein möglich, den Transformationsprozess alleine zu starten und die restlichen, noch nicht umgewandelten Daten umzuformen.

Durch dieses Prinzip stört eine stockende Datenumformung nicht die Aufzeichnung der Daten vom Scanner. Sofern der Raspberry Pi nicht die Geschwindigkeit der Umformung halten kann, werden einfach mehr binäre Dateien zwischengespeichert, welche gegebenenfalls im Postprocessing umgewandelt werden können.

5.4  Auslagerung der Transformation in C++

Da auch bei Nutzung der kompletten Prozessorleistung des Raspberry Pi es nicht möglich war, die Daten zeitgleich zu transformieren und lange Nachbearbeitungszeiten auftraten, wurden weitere Ansätze geprüft. Am erfolgversprechendsten war die Nutzung von C++ für diesen Teil. Die Programmiersprachen C und C++ sind bekannt dafür, dass sie sehr schnelle Ausführungszeiten bieten. Die Klassen, welche für die Transformation zuständig waren, wurden daher in C++ nachgebaut. Die Geschwindigkeit für die Umformung eines Testdatensatzes erfolgte in etwa der zehnfachen Geschwindigkeit. Diese Steigerung reicht aus, um bei Nutzung der vier Kerne des Raspberry Pi die Daten zeitgleich umzuformen. Der C++-Code wurde als eigenständiges Kommandozeilenprogramm erstellt. Somit ist es unabhängig vom Python-Code und kann auch selbständig verwendet werden, zum Beispiel zum späteren Umformen von Daten. Die Python-Klasse VdTransformer wurde so erweitert, dass sie das zusätzliche C++-Programm zur Umformung verwendet. Mit den Einstellungen in der Konfigurationsdatei kann gegebenenfalls auch auf die Nutzung der Python-Skripte umgeschaltet werden. So kann je nach verwendeter Umgebung zwischen der Umformung mittels Python (plattformunabhängig) und den für verschiedene Plattformen kompilierten C++-Umformungen (ARM 32bit, Linux 64bit) gewechselt werden.

5.5  Klassen

5.5.1  VdAutoStart (Python)

Die Klasse VdAutoStart (siehe Anhang A.1) steuert den automatischen Start des Skriptes beim Hochfahren des Raspberry Pi. Diese ist verantwortlich für den Start der einzelnen Skriptteile in der richtigen Reihenfolge. Außerdem sind in der zugehörigen Datei auch alle Programmteile abgelegt, die nicht zu einer Klasse gehören, wie zum Beispiel der Startaufruf und das Webinterface.

Flask-Webinterface app Die Weboberfläche zur Steuerung wird mit dem Modul Flask erzeugt. Die Weboberfläche wird in einem zusätzlichen Thread gestartet. Die Weboberfläche ist entsprechend ihrem geplanten Einsatzzweck optimiert für die mobile Anzeige auf Smartphones, lässt sich aber auch vom Laptop bedienen. Die Oberfläche selbst nutzt nur HTML und CSS – ist also nicht von zusätzlichen Skriptsprachen auf dem verwendeten Gerät abhängig. Sie ermöglicht den Start und den Stopp der Datenaufnahme, das Übertragen der aufgezeichneten Daten sowie das Herunterfahren des Raspberry Pi.

5.5.2  VdInterface (Python)

Die Klasse VdInterface (siehe Anhang A.2) übernimmt die Kommunikation mit dem Laserscanner. Sie stellt die UDP-Socket-Verbindungen zu dem GNSS- und zu dem Laserscan-Datenstream des Scanners her.

5.5.3  VdGNSSTime (Python)

Die Klasse VdGNSSTime (siehe Anhang A.3) ist dafür zuständig, die Systemzeit des Raspberry Pi zu setzen. Hierfür nutzt die Klasse die Daten des GNSS-Modules, welche über das Netzwerksignal des Laserscanners und die serielle Schnittstelle übertragen werden.

5.5.4  VdHardware (Python)

Die Klasse VdHardware (siehe Anhang A.4) übernimmt die Hardwaresteuerung des Raspberry Pi. Um etwas unabhängiger zu sein, stellt die Klasse einen eigenen Thread dar, der von der Klasse VdAutoStart je nach Hardware gestartet wird. Hierdurch werden die Abläufe des Hauptskriptes nicht durch die Abfrageschleifen der Hardwaresteuerung unterbrochen.

Bei der Initialisierung der Klasse werden die GPIO-Ports des Raspberry Pi entsprechend des Hardwaresteuerungsmodules aus Abschnitt 3.5 eingerichtet. Hierbei werden bei den Eingangsports die internen Pull-Up-Widerstände aktiviert. Bei dem Start des Threads wird dann zusätzlich ein Eventhandler für die Eingangspins eingerichtet, der entsprechende Funktionen zum Starten oder Stoppen der Aufzeichnung sowie zum Herunterfahren aufruft. Des Weiteren wird ein Timer aktiviert, der dafür sorgt, dass die Status-LEDs (siehe Abbildung 3.11) einmal sekündlich aktualisiert werden.

5.5.5  VdPoint (Python / C++)

Die VdPoint-Klasse (siehe Anhang A.5, B.4 und B.5) stellt einen Messpunkt des Velodyne VLP-16 dar. Dieser nimmt als Attribute die Messdaten auf. Außerdem bietet die Klasse die Möglichkeit, die Messdaten in lokale kartesische Koordinaten mit dem Laserscanner als Ursprung umzurechnen. Dieses wird zum Beispiel bei der Erzeugung von OBJ- und XYZ-Dateien genutzt. In C++ wurde außerdem eine zweite Klasse erstellt, um die XYZ-Daten zu übergeben zu können (VdXYZ, siehe Anhang B.2 und B.3).

5.5.6  VdDataset (Python / C++)

Die Klasse VdDataset (siehe Anhang A.6, B.6 und B.7) nimmt die Messdaten auf. Diese Klasse sorgt auch für das Interpretieren der binären Daten vom Laserscanner. Die Daten werden als VdPoint-Objekte in einer Liste gesichert. Durch die Übergabe der Daten an die Implementierungen der Klasse VdFile können diese dann als Datei gespeichert werden.

5.5.7  VdFile und Subklassen (Python / C++)

Bei der Klasse VdFile (siehe Anhang A.7, B.8 und B.9) handelt es sich um eine abstrakte Klasse. Die Klasse stellt ein Interface bereit, das die Speicherung der umgewandelten Daten übernimmt. Die genauen Datenformate werden in Klassen festgelegt, die von ihr erben:

VdASCIIFile sowie VdTxtFile, VdObjFile und VdXYZFile Die abstrakte Klasse VdASCIIFile (siehe Anhang A.8, B.10 und B.11) erweitert die Klasse VdFile um Funktionen, um ASCII-Dateien zu schreiben. VdTxtFile, VdObjFile und VdXYZFile implementieren dann die eigentlichen Dateiformate. Die Klasse VdTxtFile (siehe Anhang A.10, B.14 und B.15) schreibt hierbei die Rohdaten als einfache Textdateien (siehe Anhang D.2). VdObjFile (siehe Anhang A.9, B.12 und B.13) formt die Rohdaten in lokale Koordinaten mit dem Ursprung im Standpunkt des Scanners um und speichert die Daten als OBJ-Datei (siehe Anhang D.3). Das Dateiformat ist für das einfache Betrachten der Daten hilfreich. Es lässt sich als Punktwolke in vielen Programmen, wie zum Beispiel MeshLab, einlesen und darstellen. Im Zusammenhang mit der Vergleichsmessung aus Kapitel 7 wurde zusätzlich noch eine Klasse zur Implementierung von XYZ-Dateien (VdXYZFile, siehe Anhang A.11, B.16 und B.17) erstellt. Hier werden die schon für die OBJ-Dateien aufbereiteten Daten in anderer Formatierung genutzt. Die Daten aus der TXT-Datei können auch im Nachhinein in die anderen Dateiformate umgeformt werden. Hierfür wurde ein Konvertierungsskript erstellt (siehe Anhang A.17).

VdSQLite (Python) Die Klasse VdSQLite (siehe Anhang A.12, B.18 und B.19) ermöglicht das Speichern der Rohdaten in einer SQLite-Datenbank-Datei. Das Format bietet sich zum einfachen Übertragen und Auswerten der Daten an. Alle Daten werden in einer Datenbank-Datei gesichert. Dies erleichtert das Einladen der Daten in weitere Skripte, zum Beispiel zum Durchführen von Berechnungen.

5.5.8  VdBuffer (Python)

Die Klasse VdBuffer (siehe Anhang A.13) übernimmt die Zwischenspeicherung der binären Rohdaten vom Laserscanner. Über die Klasse VdInterface wird eine Socketverbindung zum UDP-Port des Laserscanners hergestellt. Anschließend werden die Daten vom Socket in einer Variable gespeichert und regelmäßig in kurzen Intervallen als binäre Datei auf dem Speicher des Raspberry Pi abgelegt. Hierzu wird bei dem ersten Datenempfang eine Verzeichnisstruktur für die Messung angelegt. Nach dem Schreiben der Datei wird ihr Pfad in die Warteschleife für VdTransformer eingetragen.

5.5.9  VdTransformer (Python)

VdTransformer (siehe Anhang A.14) übernimmt die Umformung der als Datei gespeicherten binären Daten in VdPoint-Objekte. Um die Leistung des jeweiligen Computersystems auszunutzen, wird durch VdAutoStart die Anzahl der Instanzen des Prozesses je nach Anzahl der Kerne des Prozessors gesteuert – auf dem Raspberry Pi als Vierkern-System beispielsweise drei Prozesse. Sofern die Daten als ASCII-File gesichert werden sollen, wird für jede Instanz eine Datei erstellt, damit sich die Schreibprozesse nicht gegenseitig stören. Aus der Warteschlange wird jeweils eine binäre Datei ausgewählt, eingelesen und an ein Objekt der Klasse VdDataset übermittelt. Nachdem dieses die Daten zu einer Liste von VdPoint-Objekten umgewandelt hat, werden diese an ein Objekt der Klasse VdFile übergeben. Das Objekt schreibt dann je nach Einstellung in der Konfigurationsdatei die Daten im gewünschten Dateiformat. Nach dem erfolgreichen Schreibvorgang, wird die binäre Datei gelöscht oder, je nach Einstellungen, in einen anderen Unterordner verschoben.

6  Konfiguration und Steuerung des Raspberry Pi

Als Grundlage wurde auf die microSD-Karte, die dem Raspberry Pi als Festplatte dient, das Betriebssystem Raspbian aufgespielt. Hierbei handelt es sich um ein Derivat von Debian GNU/Linux, das speziell auf die Hardware des Raspberry Pi angepasst ist. Die aktuelle Version (Stand 10.12.2017) nennt sich Raspbian Stretch. Für die Verwendung als Verarbeitungsgerät ohne angeschlossenen Display reicht die Variante ohne grafische Benutzeroberfläche aus (Raspbian Stretch Lite). Die Konfiguration des Raspberry Pi erfolgt vollständig über Konfigurationsdateien. In dieser Arbeit erfolgte die Konfiguration per Fernzugriff über SSH, einem Standard für das Fernsteuern der Konsole über das Netzwerk. Eine Konfiguration hätte aber auch mittels eines angeschlossenen Displays und einer USB-Tastatur erfolgen können.

Die Änderungen der Konfigurationsdateien erfolgten mit dem vorinstallierten Editor nano unter Nutzung von Administratorrechten. Ein solcher Aufruf erfolgt zum Beispiel mit dem Befehl sudo nano /pfad/zur/konfiguration.txt. Nachfolgend müssen die betroffenen Programme oder sogar das komplette Betriebssystem neu gestartet werden. Der Neustart eines Service erfolgt zum Beispiel mit dem Aufruf sudo service programmname restart, der Neustart des Betriebssystems mit sudo shutdown -r now. Es empfiehlt sich, von allen zu ändernden Konfigurationsdateien Sicherungskopien anzulegen. Dies erfolgt zum Beispiel mit sudo cp original.txt original.old.txt (Kopieren) oder sudo mv original.txt original.old.txt (Verschieben, zum Beispiel zum Anlegen einer komplett neuen Datei). Auf diese Linux-Grundlagen wird im Folgenden nicht mehr eingegangen.

6.1  Installation von Raspbian

Die Installation von Raspbian erfolgt durch das Entpacken des Installationspaketes von der Website der Raspberry Pi Foundation auf einer leeren microSD-Karte mit dem Tool Etcher. Auf der nach dem Entpacken erzeugten boot-Partition wird eine leere Datei mit dem Namen ssh angelegt. Hierdurch wird sofort nach dem Start der SSH-Zugang über das Netzwerk zum Raspberry Pi ermöglicht, die IP-Adresse wird per DHCP, zum Beispiel von einem im Netzwerk vorhandenen Router, bezogen. Nach dem Login – unter Linux beispielsweise mit dem Befehl ssh pi@raspberrypi – kann mittels passwd das Passwort verändert werden. Mit den Befehlen sudo rpi-update, sudo apt update und sudo apt upgrade wird die Firmware und das Betriebssystem auf den neusten Stand gebracht. Mit sudo apt-get install python3-pip wird der Paketmanager von Python 3 installiert. Dieser ermöglicht das einfache Installieren von zusätzlichen Modulen. Die benötigten Pakete werden mit pip3 install flask pyserial RPi.GPIO installiert. Falls der Raspberry Pi auch mit der Tastatur gesteuert werden soll, bietet es sich an, die Lokalisation einzurichten. Dies erfolgt im Konfigurationsmenü unter sudo raspi-config. Außerdem muss mit diesem Tool das Warten auf die Netzwerkverbindung bei dem Systemstart und die Nutzung der seriellen Schnittstelle als Ausgabe der Eingabekonsole deaktiviert werden.

6.2  Befehle mit Root-Rechten

Linux erlaubt das Ändern der Zeit und das Herunterfahren über die Kommandozeile nur dem Administrator (root). Da es jedoch nicht empfohlen ist, Skripte als root auszuführen, muss hier eine andere Lösung gefunden werden, um den Skripten die Möglichkeit zu geben, den Raspberry Pi auf Tastendruck oder per Web-Steuerung herunterzufahren. Hierfür wurden dem normalen Nutzer (pi) die Rechte gegeben, einzelne Befehle als Administrator ohne Passwortabfrage auszuführen. Diese Rechte können dem Nutzer durch die Eintragung in der Konfigurationsdatei /etc/sudoers gegeben werden. Da eine fehlerhafte Änderung der Datei den kompletten Administratorzugang zum System versperren kann, wird die Datei mit dem Befehl sudo visudo -f /etc/sudoers überarbeitet, der nach dem Editieren die Datei auf Fehler prüft. Die zusätzlichen Einträge in der Konfiguration sind dem Abschnitt 6.1 zu entnehmen. (Frisch, 2003, S. 33)

1# Cmnd alias specification 
2Cmnd_Alias VLP = /sbin/shutdown, /sbin/date 
 
4# User privilege specification 
5pi  ALL=(ALL) NOPASSWD: VLP

6.3  IP-Adressen-Konfiguration

Die Ethernet-Schnittstelle des Raspberry Pi soll die IP-Adresse 192.168.1.111 nutzen, da diese IP-Adresse im Laserscanner als Host voreingestellt war und an diesen die Daten vom Scanner übertragen werden. Die IP-Adresse des Raspberry Pi im WLAN wurde fest auf die gut zu merkende Adresse 10.10.10.10 geändert, hierüber erfolgt später der Zugriff auf die Weboberfläche (siehe auch Tabelle 6.1).

Die Konfiguration der IP-Adressen für den Raspberry Pi erfolgt in der Konfigurationsdatei /etc/network/interfaces (siehe Listing 6.2). Um zukünftige Updates einfach zu ermöglichen, müssen die statischen IP-Einstellungen (Zeile 8-11) im Normalfall abgeschaltet werden und die DHCP Einstellungen (Zeile 13) aktiviert werden. (Raspberry Pi Foundation, 2017)

1#localhost 
2auto lo 
3iface lo inet loopback 
 
5#Ethernet 
6auto eth0 
7## for Velodyne 
8iface eth0 inet static 
9  address 192.168.1.110 
10  netmask 255.255.255.0 
11  gateway 192.168.1.110 
12## for Internet etc. (DHCP) 
13# iface eth0 inet dhcp 
 
15allow-hotplug wlan0 
16iface wlan0 inet static 
17  address 10.10.10.10 
18  netmask 255.255.255.0 
19  network 10.10.10.0

Zur Konfiguration der dynamischen IP-Adressen der Clients im WLAN wird ein DHCP-Server eingerichtet. Ein solcher Server weißt neuen Geräten – beziehungsweise welchen, die länger nicht im Netzwerk waren – automatisch eine neue, unverwendete IP-Adresse zu. Hierdurch benötigen die Clients keine spezielle Konfiguration und ihre IP-Einstellungen können auf den üblichen Standardeinstellungen verbleiben (IP-Adresse automatisch beziehen). Als DHCP-Server wird hier das Paket dnsmasq verwendet. Außer dem DHCP-Server bietet dieses Paket auch einen DNS-Server, der es erlaubt, den Geräten auch einen Hostname zuzuweisen. So wäre der Zugriff zum Beispiel über den Hostname raspberry.ip anstatt durch Eingabe der IP-Adresse möglich.

Die Konfiguration des DHCP-Servers ist vergleichsweise einfach und benötigt nur das verwendete Netzwerk-Interface, hier wlan0, den zu nutzenden IP-Bereich, die Netzmaske und die Zeit, nach der eine IP-Adresse an ein anderes Gerät vergeben werden darf, die sogenannte Lease-Time (siehe Listing 6.3). (Raspberry Pi Foundation, 2017)

1interface=wlan0 
2  dhcp-range=10.10.10.100,10.10.10.254,255.255.255.0,24h 
3no-dhcp-interface=eth0

6.4  Konfiguration als WLAN-Access-Point

Um einen Zugriff auf die Python-Weboberfläche des Skriptes und die Konfiguration des Laserscanners zu ermöglichen, soll der Raspberry Pi selbst als WLAN-Access-Point fungieren. Hierzu wurde das Paket hostapd verwendet. Zur Konfiguration werden die Einstellungen in die Datei /etc/hostapd/hostapd.conf geschrieben. (Raspberry Pi Foundation, 2017)

1# WLAN-Router-Betrieb 
 
3# Schnittstelle und Treiber 
4interface=wlan0 
5#driver=nl80211 
 
7# WLAN-Konfiguration 
8ssid=VLPinterface 
9channel=1 
10hw_mode=g 
11ieee80211n=1 
12ieee80211d=1 
13country_code=DE 
14wmm_enabled=1 
 
16#WLAN-Verschluesselung 
17auth_algs=1 
18wpa=2 
19wpa_key_mgmt=WPA-PSK 
20rsn_pairwise=CCMP 
21wpa_passphrase=hafencity

Damit die Konfigurationsdatei auch genutzt wird, muss der Pfad in die Konfiguration von hostapd eingetragen werden (/etc/default/hostapd).

6.5  Autostart des Skriptes

Damit das Skript automatisch beim Systemstart gestartet wird, wurde das Skript in den Autostart des Raspberry Pi eingetragen. Durch die Nutzung des Befehls su wird der Befehl als Nutzer pi, also ohne Administratorrechte gestartet. Durch das Weglassen von su pi -c kann dieser auch als Administrator gestartet werden. Dies hat jedoch sicherheitstechnische Nachteile, dafür können dann Prioritäten der Befehle gesetzt werden.

1su pi -c "python3 VdAutoStart.py" 
2exit 0

Das Startskript wird mit chmod +x startVLP.sh ausführbar gemacht und der Pfad zum Skript in der Autostart-Konfigurationsdatei /etc/rc.local eingetragen.

6.6  Einrichtung als Router

Zusätzlich ist es sinnvoll, den Raspberry Pi auch als Router einzurichten. So lässt sich über die WLAN-Schnittstelle des Raspberry Pi auf die Konfigurationswebseite des Laserscanners zugreifen, um Einstellungen des Scanners mobil zu ändern. Hierfür wird die Datei /etc/network/interfaces um die Zeilen aus Abschnitt 6.6 ergänzt. (Schnabel, 2017a)

1# Firewall-Regel lschen 
2up /sbin/iptables -F 
3up /sbin/iptables -X 
4up /sbin/iptables -t nat -F 
 
6# Loopback zulassen 
7up /sbin/iptables -A INPUT -i lo -j ACCEPT 
8up /sbin/iptables -A OUTPUT -o lo -j ACCEPT 
 
10# NAT und Masquerading aktivieren 
11up /sbin/iptables -A FORWARD -o eth0 -i wlan0 -m conntrack --ctstate NEW -j ACCEPT 
12up /sbin/iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT 
13up /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE 
 
15# IP-Forwarding aktivieren 
16up sysctl -w net.ipv4.ip_forward=1 
17up sysctl -w net.ipv6.conf.all.forwarding=1 
 
19# hostapd und dnsmasq neu starten 
20up service hostapd restart 
21up service dnsmasq restart

6.7  Bedienung des Systems

Die grundlegenden Einstellungen erfolgen über die Konfigurationsdatei config.ini. Hier werden Einstellungen zum Verhalten des Skriptes durchgeführt, aber auch die Parameter des Laserscanners angepasst. Die weitere Steuerung erfolgt über die Weboberfläche des Skriptes und des Laserscanners sowie die Tasten am Steuermodul.

Nach dem Start des Raspberry Pi, erkennbar an dem Ausgehen der obersten LED (Datenempfang), kann sich mit einem WLAN-fähigen Endgerät in das WLAN-Netzwerk VLPinterface mit dem dazugehörigen Schlüssel hafencity eingeloggt werden. Unter der Adresse http://10.10.10.10:8080/ (siehe Abbildung 6.1, links) ist dann das Webinterface des Raspberry Pi zu erreichen. Das Interface ermöglicht es, genauso wie die Tasten auf dem Hardware-Steuerungsmodul, die Aufzeichnung zu starten und zu stoppen, sowie den Raspberry Pi herunterzufahren.

Nach dem ein stabiles GNSS-Signal vom uBlox-Chip empfangen wird, erkennbar an der blinkenden LED am Chip oder der Meldung auf der Website, kann der Laserscanner gestartet werden. Der Laserscanner synchronisiert nun seine Zeit mit dem GNSS-Modul. Dies kann über seine Weboberfläche kontrolliert werden (siehe Abbildung 6.1, rechts). Die Messung kann gestartet werden (linke Taste). Ob Daten empfangen und gesichert werden, ist an den LEDs und im Webinterface sichtbar. Die untere LED zeigt an, dass die Aufzeichnung läuft, die obere, dass Daten empfangen werden. Die mittlere zeigt an, ob Daten noch nicht transformiert wurden und in der Warteschleife sind.

Nach dem Stoppen der Messung (mittlere Taste), erlischt die untere und die obere LED. Kurz nachdem die gegebenenfalls leuchtende, mittlere Warteschlangen-LED erlischt, kann der Raspberry Pi heruntergefahren werden (rechte Taste). Falls die Daten direkt übertragen werden sollen, kann über das Webinterface (siehe Abbildung 6.1, Mitte) auf umgewandelte Dateien zugegriffen werden. Alternativ kann nach dem Herunterfahren die microSD-Karte herausgenommen werden und die Daten aus dem Verzeichnis _daten kopiert werden.

Die Einstellungen in der config.ini (siehe Anhang A.15) können über eine SSH-Verbindung oder durch Herausnehmen der microSD-Karte geändert werden.

7  Systemüberprüfungen

Nachdem bei der Systemkonfiguration bisher auf die Angaben aus Handbüchern und Anleitungen vertraut wurde, sollte zusätzlich die Genauigkeit von einigen Systemkomponenten und der Programmierung überprüft werden. Hierfür wurde einmal die Messgenauigkeit des Scanners ausgewählt sowie die Genauigkeit der Zeitangaben der GNSS-Systeme. Die Genauigkeit des GNSS und der in Zusammenhang mit der IMU zu berechnenden Trajektorie hatte bereits Wilken (2017) in seiner Bachelorthesis untersucht.

7.1  Untersuchung der Gleichzeitigkeit von PPS-Signalen von verschiedenen GNSS-Empfängern

Für die Synchronisierung der Daten des Laserscanners und der inertialen Messeinheit wurden zwei verschiedene GNSS-Empfänger verwendet. Der für den Einbau in Consumer-Geräte gedachte uBlox-Chip, der am Raspberry Pi und am Laserscanner verwendet wird, ist leichter, unabhängiger und einfacher zu realisieren als die Übernahme der Daten mittels Adapterkabeln von der inertialen Messeinheit. Voraussetzung hierfür ist jedoch, dass beide Signale wirklich gleichzeitig erzeugt werden. Laut Datenblatt (uBlox AG, 2011) hat der Zeitimpuls der UBlox NEO-6M eine Standardabweichung von 30 Nanosekunden, das Signal des IMU von unter 10 Nanosekunden (iMAR Navigation GmbH, 2015). Diese Genauigkeit wäre deutlich besser, als benötigt. Um zu überprüfen, ob sich diese Angabe auch auf die einheitliche GNSS-Zeit bezieht, soll das PPS-Signal (Impulssignal im Sekundentakt) von beiden Messsystemen mit einem Arduino überprüft werden. Am Arduino werden hierzu an zwei digitalen Eingängen die PPS-Anschlüsse der GNSS-Empfänger angeschlossen. Ein Skript (siehe Anhang C.1) misst dann die Zeit zwischen den beiden Signalen. Diese Messungen werden dann mehrfach hintereinander sowie nach einem Neustart der Systeme durchgeführt. Hiermit soll überprüft werden, ob sich bei einem Neustart der Messung die Zeitdifferenz ändert beziehungsweise dann überhaupt eine Zeitdifferenz entsteht.

Der Test zeigte, dass das Skript keine Zeitdifferenz messen konnte. Daher wurde auf dem Arduino nochmals das Oszilloskop-ähnliche Skript installiert, dass auch schon bei der Untersuchung der NMEA-Übertragung zum Laserscanner genutzt wurde. Hier zeigte sich, dass das PPS-Signal der IMU ein LOW-Signal und nicht wie erwartet ein HIGH-Impuls absendet. Dennoch wurde bei einer Abtastrate von 450 Messungen pro Sekunde keine Zeitdifferenz festgestellt (siehe Abbildung 7.1). Außerdem konnte hiermit auch festgestellt werden, dass das Signal der IMU nicht den Anforderungen des Velodyne VLP-16 entspricht: Hier wird ein Signal mit einer Impulsdauer von mindestens 10 ms gefordert. Dies wird scheinbar nicht eingehalten, da der Arduino, der mit einer Taktrate von 2,2 ms misst, nicht alle Signale der IMU erkennen konnte (siehe erster Puls auf Abbildung 7.1). Außerdem müsste auch hier das Signal elektrisch gedreht werden.

7.2  Messgenauigkeit des Laserscanners im Vergleich

Um die Strecken und Winkelmessung des Laserscanners und die Umwandlung der Daten zu überprüfen, wurden drei verschiedene Messungen an der HafenCity Universität mit dem Velodyne VLP-16 durchgeführt.

Zusätzliches Datenformat Die Daten des Velodyne VLP-16 wurden mit dem in dieser Arbeit entwickelten Skript aufgezeichnet und umgewandelt. Da hierbei auffiel, dass einige Programme besser mit XYZ-Dateien umgehen können, wurde das Klassenmodell um dieses Dateiformat erweitert.

7.2.1  Versuchsmessung in der Tiefgarage

Hauptsächlich zur Überprüfung der Umformung der Daten, aber auch zur Überprüfung der Streckenmessung und Winkelmessungen wurde eine Messung in der Tiefgarage (Abbildung 7.2, rechts) durchgeführt. Durch die vielen rechtwinkligen Pfeiler sind hier viele Möglichkeiten gegeben um Kanten zu detektieren. Die meisten Oberflächen bestanden hier aus weiß gestrichenem Beton. Zum Vergleich wurde die Tiefgarage mit einem Trimble S7 mit einer Winkelgenauigkeit von 1 mgon und einer prismenlosen Streckengenauigkeit von 2 mm + 2 ppm aufgemessen (Trimble Inc., 2017).

Auswertung Aus den Daten der Tachymeter-Messung wurden die Wände und Pfeiler der Tiefgarage modelliert. Durch Anpassung der Laserscandaten an diesen Grundriss wurde die Orientierung des Velodyne VLP-16 bestimmt. Hierfür wurden jeweils Ebenen in die gemessenen Punkte des Velodyne Pfeiler- und Wandoberflächen in Geomagic Wrap mittels Ausgleichung eingepasst. Die Neigung wurde durch eine Ausgleichung der Fußbodenebene mit der XY-Ebene des Tachymeter-Koordinatensystems bestimmt.

Fehler im Skript Bei der Auswertung der Messung fiel schon vor dem Vergleich mit der Tachymeter-Messung auf, dass die Messwerte in Rotationsrichtung verschoben waren. Die Analyse ergab einen Umformungsfehler in der Klasse VdDataset. Hierdurch wurden die Horizontalrichtungen um bis zu 2 Grad (bei 1200 Umdrehungen pro Minute) fehlerhaft berechnet (siehe Abbildung 7.3). Bei der Messung der Tiefgarage wurden glücklicherweise auch die Rohdaten von zwei der fünf Messreihen gespeichert, so dass hier keine erneute Messung vor Ort nötig war. Die Daten der Fassadenmessung (Abbildung 7.2, links) mussten nochmals wiederholt werden, da die Daten nicht auswertbar waren.

Weitere Ergebnisse An den Pfeilern, von denen zwei Seiten gut modellierbar waren (siehe zum Beispiel Abbildung 7.4), wurden die Standardabweichungen verglichen, um zu prüfen, ob weitere Fehler in der Berechnung der Horizontalrichtungen vorhanden waren. Die Standardabweichungen und die durchschnittlichen Abweichungen zu den Ebenen der Tachymeter-Messung waren auf beiden Seiten ähnlich, so dass von keinen weiteren Fehlern ausgegangen wurde.

7.2.2  Vergleichsmessung an einer Fassadenfront / im geodätischen Labor

Eine weitere Messung fand etwa 20 m vor einer weißen, rauen und ebenen Fassade (verputztes Wärmedämmverbundsystem) statt. Hier wurden zum Vergleich der Messaufbau komplett von zwei Standpunkten aus mit dem terrestrischem Laserscanner Zoller+Fröhlich Imager 5010 gescannt. Durch einen Fehler im Auswerteskript, der erst bei großen Strecken auffiel, waren die Messdaten jedoch leider nicht zu verwenden. Es wurde daher eine ähnliche Messung im geodätischen Labor nachgeholt (siehe Abbildung 7.5). Hier wurde der Velodyne VLP-16 mittig im Raum aufgestellt. Zwei Stellwände wurden zur Überprüfung der Entfernungsmessung verwendet. Eine verblieb hierbei immer an der gleichen Stelle, etwa 5 m vom Velodyne entfernt stehen, die zweite wurde in verschiedenen Entfernungen zwischen 6 und 26 m aufgestellt. Die Messszenarien wurden jeweils mit dem terrestrischen Laserscanner Imager 5010 von Zoller+Fröhlich dokumentiert. Bei Messungen auf weißen Oberflächen liegt die Streckenmessgenauigkeit des Vergleichsscanners unter einem Millimeter (Zoller + Fröhlich GmbH, 2017). Zum Vergleich mit dem Velodyne VLP-16, der eine angegebene Genauigkeit von 3 cm hat (Velodyne Lidar Inc., 2017b), wird die Messung des Imagers daher als wahrer Wert angenommen.

Nachbearbeitung der Messdaten Die Punktwolken des Imager 5010 wurden in der Software Z+F LaserControl über angebrachte Targets zusammengeführt. Anschließend wurden die Punktwolken gefiltert und in die Software Geomagic Wrap importiert. Hier wurde der Standpunkt des Velodyne VLP-16 bestimmt, in dem ein Zylinder der Größe des VLP-16 automatisch in die ihm zuzuordnenden Punkte der Punktwolke eingepasst wurde. Aus diesen konnte dann der Nullpunkt der Messungen des Velodyne VLP-16 bestimmt werden.In den Laserpunktwolken der beiden Scanner wurden in Geomagic Wrap die Wände, die Decke, der Fußboden und die Stellwände modelliert. Die entsprechenden Punkte wurden ausgewählt und mittels Best-Fit-Anpassung Ebenen durch diese ausgeglichen. Über die Wände, die Decke und den Boden wurden die Punktwolken nochmals genauer zu einander ausgerichtet.

Präzision der Streckenmessung Beim Modellieren der Wände bestand die Möglichkeit, sich die Genauigkeit der Ausgleichung in den Punkten anzuzeigen. Die maximale bestimmte Standardabweichung in der Ausgleichung der Ebenen lag bei etwa 2,4 cm (Ausgleichung der Decke). Die Standardabweichung der Stellwände (siehe Spalte 3, Tabelle 7.1) lag bei maximal 1,3 cm. Die Angaben wurden bei der Wiederholungsmessung also eingehalten.

Richtigkeit der Streckenmessung Um zu überprüfen, ob nicht nur die Wiederholungsgenauigkeit des Velodyne VLP-16 im angegeben Bereich liegt, wurden die Positionen der modellierten Stellwände aus den Datensätzen des Velodyne mit denen des Imager 5010 verglichen. In Geomagic Wrap wurde die Abweichung der Punkte des Velodyne zu den Ebenen aus der Messung des Imager 5010 bestimmt. Hier lag die Standardabweichung nur minimal über den Werten der Ausgleichung der Messwerte selbst (siehe Spalte 4, Tabelle 7.1). Die durchschnittliche Abweichung (Spalte 5) zeigt, dass die etwas höhere Standardabweichung auch in der Einpassung der Daten liegen kann, denn die durchschnittliche Abweichung zeigt eine Korrelation mit der Entfernung. Es zeigt sich, dass der Velodyne seine angegebene Genauigkeit einhält.

8  Fazit & Ausblick

Die Arbeit hat gezeigt, dass es mit dem Raspberry Pi möglich ist, die Daten vom Laserscanner Velodyne VLP-16 zu erfassen und weiterzuverarbeiten. Der Raspberry Pi stößt hierbei jedoch teilweise an seine Leistungsgrenzen. Bis zu diesem Ergebnis war jedoch viel Einarbeitung in verschiedenste Themenbereiche notwendig. Die Aufgabe zeigte, wie schnell Themen der Geodäsie auch in die Bereiche der Elektrotechnik und der Informatik hineinreichen. Vor der gemeinsamen Nutzung der Systeme, mussten erst ihre Schnittstellen, vor allem die des Laserscanners, analysiert werden. Auch wenn die Dokumentation des Velodyne sehr ausführlich ist, waren nicht alle Schnittstellen klar verständlich beschrieben. Anschließend wurde auf dieser Basis eine entsprechende Schaltung zum Anpassen der Signale entwickelt. Bei der Realisierung der Steuerung und Aufzeichnung musste hingegen in die Informatik eingestiegen werden. Es wurde sich in zwei Programmiersprachen und in die Netzwerkkonfiguration von Unix-Systemen eingearbeitet, um die Daten empfangen und verarbeiten zu können.

Das fertige System hätte zukünftig viele mögliche Anwendungsfelder. Da es keine Abhängigkeiten vom Multikopter hat, kann es nicht nur fliegend, sondern auch terrestrisch verwendet werden. Einzige Bedingung der Nutzung ist die freie Sicht zum Himmel für den GNSS-Empfang. Auch eine Montage des Systems, gegebenenfalls auch unter Nutzung der Gimbal, an andere, bodengebundene Fahrzeuge wäre denkbar. Hiermit ließen sich beispielsweise Straßenzügen für 3D-Stadtmodelle digitalisieren. Zuerst würden die Straßen und Wege mit Autos, Fahrrädern oder einem Bollerwagen bodengebunden aufgenommen werden und anschließend mit dem gleichen Messsystem, an einem Multikopter montiert, von oben gescannt werden. So wäre mit einem Messesystem die nahtlose Erfassung von Gebäudehülle möglich.

Zu einem fertigen, mobilien Laserscanningsystem fehlen jedoch noch einige Schritte. Vorallem die Berechnung der Trajektorie ist hierbei eine große Aufgabe. In den folgenden Absätzen wird auf die noch fehlenden Schritte eingegangen.

Weiterverarbeitung der Daten Die Umformung und Speicherung der Daten war nur ein erster Schritt zur Entwicklung des Airborne Laserscanning Systems. Es ist so zwar möglich, die Daten vom Laserscanner, der inertialen Messeinheit und des GNSS zu speichern, jedoch müssen diese Daten weiter prozessiert werden. Bisher wurde der Scanner nur stationär zur Messung eingesetzt. Um ihn auch kinematisch nutzen zu können, müssen aus den Daten der IMU die Bewegungen rekonstruiert werden. Hiermit können dann die Messungen in ein übergeordnetes Bezugssystem überführt werden. Diese Verarbeitung wird in einer Folgearbeit behandelt werden.

Weitere Genauigkeitsüberprüfungen Die bisherigen Prüfungen wurden hauptsächlich zur Kontrolle auf Fehler in der Berechnung und Auswertung durchgeführt. Vor allem die Messgenauigkeit des Laserscanners ist noch deutlich detaillierter zu untersuchen. Aber auch die Zeitdifferenzen zwischen den Systemen sollten vor einem produktiven Einsatz noch weiter analysiert werden.

Erweiterungs- und Optimierungsmöglichkeiten der Software In der Programmierung des Raspberry Pi sind noch Optimierungen möglich. So ist beispielsweise das Übertragen der Messdaten noch verbesserungswürdig. Bisher muss hierfür entweder die microSD-Karte aus dem Raspberry Pi entfernt werden, eine Verbindung zum Dateisystem über SSH genutzt werden oder aber die Daten über WLAN aus der Weboberfläche heruntergeladen werden. Hier könnte zum Beispiel die Möglichkeit geschaffen werden, die Daten auf einen angesteckten USB-Stick übertragen zu lassen. Programmiertechnisch könnten auch die restlichen Skripte noch in ihrer Geschwindigkeit der Ausführung optimiert werden, beispielsweise in dem auch diese in C++ neugeschrieben werden.

Gehäuse Auch das Gehäuse befindet sich noch in der Entwicklung. Bisher existiert nur ein mit einem 3D-Drucker erstellter Entwurf (siehe Abbildung 8.1). Jedoch ist dieser noch zu instabil, um im Flug die Technik zu halten. Eine Möglichkeit wäre es, ein solches, gelochtes Gehäuse aus Aluminium zu bauen. Außerdem sollten vor einem Einsatz auch noch die Kabel entsprechend der benötigten Länge konfektioniert werden, um die Gefahr des Hängenbleibens zu vermindern.

Literaturverzeichnis

Abbildungsverzeichnis

Anhang

A  Python-Skripte

A.1  vdAutoStart.py

1#!/usr/bin/env python 
2# -*- coding: utf-8 -*- 
 
4""" 
5@author: Florian Timm 
6@version: 2017.12.12 
7""" 
 
9import configparser 
10import multiprocessing 
11import os 
12import signal 
13import sys 
14import time 
15import glob 
16import urllib 
17from datetime import datetime 
18from multiprocessing import Queue, Manager 
19from threading import Thread 
 
21from flask import Flask, request, send_file 
22from vdBuffer import VdBuffer 
23from vdTransformer import VdTransformer 
 
25from vdGNSSTime import VdGNSSTime 
 
 
28class VdAutoStart(object): 
 
30    """ main script for automatic start """ 
 
32    def __init__(self, web_interface): 
33        """ 
34        Constructor 
35        :param web_interface: Thread with Flask web interface 
36        :type web_interface: Thread 
37        """ 
38        self.__vd_hardware = None 
39        print("Data Interface for VLP-16\n") 
 
41        # load config file 
42        self.__conf = configparser.ConfigParser() 
43        self.__conf.read("config.ini") 
 
45        # variables for child processes 
46        self.__pBuffer = None 
47        self.__pTransformer = None 
 
49        # pipes for child processes 
50        manager = Manager() 
51        self.__gnss_status = "(unknown)" 
52        # self.__gnssReady = manager.Value(’gnssReady’,False) 
53        self.__go_on_buffer = manager.Value(’_go_on_buffer’, False) 
54        self.__go_on_transform = manager.Value(’_go_on_transform’, False) 
55        self.__scanner_status = manager.Value(’__scanner_status’, "(unknown)") 
56        self.__dataset_cnt = manager.Value(’__dataset_cnt’, 0) 
57        self.__date = manager.Value(’__date’, None) 
 
59        # queue for transformer 
60        self.__queue = Queue() 
 
62        # attribute for web interface 
63        self.__web_interface = web_interface 
 
65        # check admin 
66        try: 
67            os.rename(’/etc/foo’, ’/etc/bar’) 
68            self.__admin = True 
69        except IOError: 
70            self.__admin = False 
 
72        # check raspberry pi 
73        try: 
74            import RPi.GPIO 
75            self.__raspberry = True 
76        except ModuleNotFoundError: 
77            self.__raspberry = False 
 
79        self.__gnss = None 
 
81    def run(self): 
82        """ start script """ 
 
84        # handle SIGINT 
85        signal.signal(signal.SIGINT, self.__signal_handler) 
 
87        # use hardware control on raspberry pi 
88        if self.__raspberry: 
89            print("Raspberry Pi was detected") 
90            from vdHardware import VdHardware 
91            self.__vd_hardware = VdHardware(self) 
92            self.__vd_hardware.start() 
93        else: 
94            print("Raspberry Pi could not be detected") 
95            print("Hardware control deactivated") 
 
97        # set time by using gnss 
98        if self.__conf.get("functions", "use_gnss_time") == "True": 
99            self.__gnss = VdGNSSTime(self) 
100            self.__gnss.start() 
 
102    def start_transformer(self): 
103        """ Starts transformer processes""" 
104        print("Start transformer...") 
105        # number of transformer according number of processor cores 
106        if self.__conf.get("functions", "activateTransformer") == "True": 
107            self.__go_on_transform.value = True 
108            n = multiprocessing.cpu_count() - 1 
109            if n < 2: 
110                n = 1 
111            max = int(self.__conf.get("functions", "maxTransformer")) 
112            if max < n: 
113                n = max 
114            self.__pTransformer = [] 
115            for i in range(n): 
116                t = VdTransformer(i, self) 
117                t.start() 
118                self.__pTransformer.append(t) 
 
120            print(str(n) + " transformer started!") 
 
122    def start_recording(self): 
123        """ Starts recording process""" 
124        if not (self.__go_on_buffer.value and self.__pBuffer.is_alive()): 
125            self.__go_on_buffer.value = True 
126            print("Recording is starting...") 
127            self.__scanner_status.value = "recording started" 
128            # buffering process 
129            self.__pBuffer = VdBuffer(self) 
130            self.__pBuffer.start() 
131        if self.__pTransformer is None: 
132            self.start_transformer() 
 
134    def stop_recording(self): 
135        """ stops buffering data """ 
136        print("Recording is stopping... (10 seconds timeout before kill)") 
137        self.__go_on_buffer.value = False 
138        self.__date.value = None 
139        if self.__pBuffer is not None: 
140            self.__pBuffer.join(10) 
141            if self.__pBuffer.is_alive(): 
142                print("Could not stop process, it will be killed!") 
143                self.__pBuffer.terminate() 
144            print("Recording terminated!") 
145        else: 
146            print("Recording was not started!") 
 
148    def stop_transformer(self): 
149        """ Stops transformer processes """ 
150        print("Transformer is stopping... (10 seconds timeout before kill)") 
151        self.__go_on_transform.value = False 
152        if self.__pTransformer is not None: 
153            for pT in self.__pTransformer: 
154                pT.join(15) 
155                if pT.is_alive(): 
156                    print( 
157                        "Could not stop process, it will be killed!") 
158                    pT.terminate() 
159            print("Transformer terminated!") 
160        else: 
161            print("Transformer was not started!") 
 
163    def stop_web_interface(self): 
164        """ Stop web interface -- not implemented now""" 
165        # Todo 
166        # self.__web_interface.exit() 
167        # print("Web interface stopped!") 
168        pass 
 
170    def stop_hardware_control(self): 
171        """ Stop hardware control """ 
172        if self.__vd_hardware is not None: 
173            self.__vd_hardware.stop() 
174            self.__vd_hardware.join(5) 
 
176    def stop_children(self): 
177        """ Stop child processes and threads """ 
178        print("Script is stopping...") 
179        self.stop_recording() 
180        self.stop_transformer() 
181        self.stop_web_interface() 
182        self.stop_hardware_control() 
183        print("Child processes stopped") 
 
185    def end(self): 
186        """ Stop script complete """ 
187        self.stop_children() 
188        sys.exit() 
 
190    def __signal_handler(self, sig_no, frame): 
191        """ 
192        handles SIGINT-signal 
193        :param sig_no: signal number 
194        :type sig_no: int 
195        :param frame:execution frame 
196        :type frame: frame 
197        """ 
198        del sig_no, frame 
199        print(’Ctrl+C pressed!’) 
200        self.stop_children() 
201        sys.exit() 
 
203    def shutdown(self): 
204        """ Shutdown Raspberry Pi """ 
205        self.stop_children() 
206        os.system("sleep 5s; sudo shutdown -h now") 
207        print("Shutdown Raspberry...") 
208        sys.exit(0) 
 
210    def check_queue(self): 
211        """ Check, whether queue is filled """ 
212        if self.__queue.qsize() > 0: 
213            return True 
214        return False 
 
216    def check_recording(self): 
217        """ Check data recording by pBuffer """ 
218        if self.__pBuffer is not None and self.__pBuffer.is_alive(): 
219            return True 
220        return False 
 
222    def check_receiving(self): 
223        """ Check data receiving """ 
224        x = self.__dataset_cnt.value 
225        time.sleep(0.2) 
226        y = self.__dataset_cnt.value 
227        if y - x > 0: 
228            return True 
229        return False 
 
231    # getter/setter methods 
232    def __get_conf(self): 
233        """ 
234        Gets config file 
235        :return: config file 
236        :rtype: configparser.ConfigParser 
237        """ 
238        return self.__conf 
 
240    conf = property(__get_conf) 
 
242    def __get_gnss_status(self): 
243        """ 
244        Gets GNSS status 
245        :return: GNSS status 
246        :rtype: Manager 
247        """ 
248        return self.__gnss_status 
 
250    def __set_gnss_status(self, gnss_status): 
251        """ 
252        Sets GNSS status 
253        :param gnss_status: gnss status 
254        :type gnss_status: str 
255        """ 
256        self.__gnss_status = gnss_status 
 
258    gnss_status = property(__get_gnss_status, __set_gnss_status) 
 
260    def __get_go_on_buffer(self): 
261        """ 
262        Should Buffer buffer data? 
263        :return: go on buffering 
264        :rtype: Manager 
265        """ 
266        return self.__go_on_buffer 
 
268    go_on_buffer = property(__get_go_on_buffer) 
 
270    def __get_go_on_transform(self): 
271        """ 
272        Should Transformer transform data? 
273        :return: go on transforming 
274        :rtype: Manager 
275        """ 
276        return self.__go_on_transform 
 
278    go_on_transform = property(__get_go_on_transform) 
 
280    def __get_scanner_status(self): 
281        """ 
282        Gets scanner status 
283        :return: 
284        :rtype: Manager 
285        """ 
286        return self.__scanner_status 
 
288    scanner_status = property(__get_scanner_status) 
 
290    def __get_dataset_cnt(self): 
291        """ 
292        Gets number of buffered datasets 
293        :return: number of buffered datasets 
294        :rtype: Manager 
295        """ 
296        return self.__dataset_cnt 
 
298    dataset_cnt = property(__get_dataset_cnt) 
 
300    def __get_date(self): 
301        """ 
302        Gets recording start time 
303        :return: timestamp starting recording 
304        :rtype: Manager 
305        """ 
306        return self.__date 
 
308    def __set_date(self, date): 
309        """ 
310        Sets recording start time 
311        :param date: timestamp starting recording 
312        :type date: datetime 
313        """ 
314        self.__date = date 
 
316    #: recording start time 
317    date = property(__get_date, __set_date) 
 
319    def __is_admin(self): 
320        """ 
321        Admin? 
322        :return: Admin? 
323        :rtype: bool 
324        """ 
325        return self.__admin 
 
327    admin = property(__is_admin) 
 
329    def __get_queue(self): 
330        """ 
331        Gets transformer queue 
332        :return: transformer queue 
333        :rtype: Queue 
334        """ 
335        return self.__queue 
 
337    queue = property(__get_queue) 
 
 
340# web control 
341app = Flask(__name__) 
 
 
344@app.route("/") 
345def web_index(): 
346    """ index page of web control """ 
347    runtime = "(inactive)" 
348    pps = "(inactive)" 
349    if ms.date.value is not None: 
350        time_diff = datetime.now() - ms.date.value 
351        td_sec = time_diff.seconds + \ 
352            (int(time_diff.microseconds / 1000) / 1000.) 
353        seconds = td_sec % 60 
354        minutes = int((td_sec // 60) % 60) 
355        hours = int(td_sec // 3600) 
 
357        runtime = ’{:02d}:{:02d}:{:06.3f}’.format(hours, minutes, seconds) 
 
359        pps = ’{:.0f}’.format(ms.dataset_cnt.value / td_sec) 
 
361    elif ms.go_on_buffer.value: 
362        runtime = "(no data)" 
 
364    output = """<html> 
365    <head> 
366        <title>VLP16-Data-Interface</title> 
367        <meta name="viewport" content="width=device-width; initial-scale=1.0;" /> 
368        <link href="/style.css" rel="stylesheet"> 
369        <meta http-equiv="refresh" content="5; URL=/"> 
370    </head> 
371    <body> 
372    <content> 
373        <h2>VLP16-Data-Interface</h2> 
374        <table> 
375            <tr><td id="column1">GNSS-status:</td> 
376            <td>""" + ms.gnss_status + """</td></tr> 
377            <tr><td>Scanner:</td> 
378            <td>""" + ms.scanner_status.value + """</td></tr> 
379            <tr><td>Datasets</td> 
380                <td>""" + str(ms.dataset_cnt.value) + """</td></tr> 
381            <tr><td>Queue:</td> 
382                <td>""" + str(ms.queue.qsize()) + """</td></tr> 
383            <tr><td>Recording time:</td> 
384                <td>""" + runtime + """</td> 
385            </tr> 
386            <tr><td>Points/seconds:</td> 
387                <td>""" + pps + """</td> 
388            </tr> 
389        </table><br /> 
390                """ 
391    if ms.check_recording(): 
392        output += """<a href="/stop" id="stop"> 
393            Stop recording</a><br />""" 
394    else: 
395        output += """<a href="/start" id="start"> 
396            Start recording</a><br />""" 
397    # <a href="/exit" id="exit">Terminate script<br /> 
398    #   (control by SSH available only)</a><br /> 
399    output += """ 
400        <a target="vlp" href="http://""" + \ 
401        ms.conf.get("network", "Config_IP") + \ 
402        """" id="vlp">Open Velodyne Config</a><br /> 
403        <a href="/files" id="files">Show files</a><br /> 
404        <a href="/shutdown" id="shutdown">Shutdown Raspberry Pi</a> 
405    </content> 
406    </body> 
407    </html>""" 
 
409    return output 
 
 
412@app.route("/style.css") 
413def css_style(): 
414    """ css file of web control """ 
415    return """ 
416    body, html, content { 
417        text-align: center; 
418    } 
 
420    content { 
421        max-width: 15cm; 
422        display: block; 
423        margin: auto; 
424    } 
 
426    table { 
427        border-collapse: collapse; 
428        width: 90%; 
429        margin: auto; 
430    } 
 
432    td { 
433        border: 1px solid black; 
434        padding: 1px 2px; 
435    } 
 
437    td#column1 { 
438        width: 30%; 
439    } 
 
441    a { 
442        display: block; 
443        width: 90%; 
444        padding: 0.5em 0; 
445        text-align: center; 
446        margin: auto; 
447        color: #fff; 
448    } 
 
450    table a { 
451        color: #000; 
452    } 
 
454    a#stop { 
455        background-color: #e90; 
456    } 
 
458    a#shutdown { 
459        background-color: #b00; 
460    } 
 
462    a#start { 
463        background-color: #1a1; 
464    } 
 
466    a#vlp { 
467        background-color: #070; 
468    } 
 
470    a#exit { 
471        background-color: #f44; 
472    } 
 
474    a#files { 
475        background-color: #444; 
476    } 
477    """ 
 
 
480@app.route("/shutdown") 
481def web_shutdown(): 
482    """ web control: shutdown """ 
483    ms.shutdown() 
484    return """ 
485    <meta http-equiv="refresh" content="3; URL=/"> 
486    Shutdown...""" 
 
 
489@app.route("/files") 
490def web_files(): 
491    """ web control: get files """ 
492    ausgabe = """<html> 
493    <head> 
494        <title>VLP16-Data-Interface</title> 
495        <meta name="viewport" content="width=device-width; initial-scale=1.0;" /> 
496        <link href="/style.css" rel="stylesheet"> 
497    </head> 
498    <body> 
499    <content> 
500        <h2>VLP16-Data-Interface</h2> 
501        <h3>File Downloader</h3> 
502        <table>""" 
503    files = glob.glob(ms.conf.get("file", "namePre") + "*/*.*") 
504    filesS = sorted(files, reverse=True) 
505    for f in filesS: 
506        ausgabe += "<tr><td>" + f + "</td><td>" + \ 
507                   "{:.1f}".format(os.path.getsize(f) / 1024 / 1024) + \ 
508                   " MB</td><td><a href=\"/file?file=" + \ 
509                   urllib.parse.quote_plus(f) + \ 
510                   "\">Download</a></td></tr>" 
 
512    ausgabe += "</table></body></html>" 
513    return ausgabe 
 
 
516@app.route("/file", methods=[’GET’]) 
517def web_file(): 
518    if request.method == ’GET’: 
519        datei = request.args.get(’file’) 
520        if datei.startswith(ms.conf.get("file", "namePre")): 
521            return send_file(datei, as_attachment=True) 
522    return "" 
 
 
525@app.route("/exit") 
526def web_exit(): 
527    """ web control: exit """ 
528    ms.end() 
529    return """ 
530    <meta http-equiv="refresh" content="3; URL=/"> 
531    Terminating...""" 
 
 
534@app.route("/stop") 
535def web_stop(): 
536    """ web control: stop buffering """ 
537    ms.stop_recording() 
538    return """ 
539    <meta http-equiv="refresh" content="3; URL=/"> 
540    Recording is stopping...""" 
 
 
543@app.route("/start") 
544def web_start(): 
545    """ web control: start buffering """ 
546    ms.start_recording() 
547    return """ 
548    <meta http-equiv="refresh" content="3; URL=/"> 
549    Recording is starting...""" 
 
 
552def start_web(): 
553    """ start web control """ 
554    print("Web server is starting...") 
555    app.run(’0.0.0.0’, 8080) 
 
 
558if __name__ == ’__main__’: 
559    w = Thread(target=start_web) 
560    ms = VdAutoStart(w) 
561    w.start() 
562    ms.run()