Experimentelle Studie mit RACOON und Epos zur ...mediatum.ub.tum.de/doc/1443240/1443240.pdf · the...

Lehrstuhl für Raumfahrttechnik

Prof. Prof. h.c. Dr. Dr. h.c. Ulrich Walter

Technische Universität München

Betreuer: Dipl.-Ing. Martin Dziura

Lehrstuhl für Raumfahrttechnik Technische Universität München

Bachelorarbeit

Experimentelle Studie mit RACOON und EPOS zur quantitativen Bewertung von Einflussfaktoren auf die

Qualität einer 3D-Objektrekonstruktion im Erdorbit

RT-BA 2017/01

Autor:

Rehn Flavio

Experimentelle Studie mit RACOON und EPOS zur quantitativen Bewertung von Einflussfaktoren auf die Qualität einer 3D-Objektrekonstruktion im

Erdorbit Rehn, Flavio

Seite II

Danksagung

Hiermit möchte ich mich bei Freunden, Familie und Kollegen bedanken, die mich bei der Erstellung dieses Dokuments tatkräftig unterstützt haben.

Großer Dank gebührt dabei meinem Betreuer am LRT Herr Martin Dziura, der mich stets mit Tipps versorgte und mir immer, solange es sein vollgepackter Zeitplan erlaubte, bei Problemen half.

Ein ebenso großer Dank gebührt meiner Betreuerin beim DLR Frau Dr. Heike Benninghoff, die mir durch ihr Engagement ermöglichte tolle zwei Monate am Standort in Oberpfaffenhofen zu verbringen. Des Weiteren möchte ich mich bei allen Mitarbeitern der Einrichtung für Raumflugbetrieb und Astronautentraining bedanken für ihre stetige Hilfeleistung bei meinen Experimenten an der EPOS-Anlage.

Zu Letzt möchte ich mich bei allen bedanken, die mich bei der Korrektur dieser Arbeit ausgezeichnet unterstützt haben:

Felix Fellner, Julia Petersen, Lilia Castillio de Rehn, Matthias Beck, Wolfgang Rehn, Xiaoyu Zhou.



Seite III

Zusammenfassung

Der prognostizierte Zuwachs von Weltraummüll stellt eine zunehmende Problematik für die Raumfahrt dar. Daher wurden in den letzten Jahren verstärkt Untersuchungen im Bereich des On-Orbit Sevicings unternommen. Dabei besteht ein wesentlicher Teil der Mission in der kontrollierten Annäherung an ein Zielobjekt. Zur Unterstützung von Regelungsalgorithmen oder menschlichen Teleoperatoren ist es hilfreich, Lage und Form des Objekts zu ermitteln, digital zu erfassen und letztendlich das Objekt dreidimensional zu rekonstruieren.

Für die 3D-Rekonstruktion von unbekannten, unkooperativen Objekten stehen eine Vielzahl an Tracking- und Mappingalgorithmen zur freien Verfügung. Aufgabe einer vorhergehenden Arbeit war es ein flexibles Softwareframework zu entwickeln, welches erlaubt verschiedene Tracking- und Mappingalgorithmen zu erproben. Es konnte in Erfahrung gebracht werden, dass nicht nur die verwendeten Algorithmen, sondern auch die vorherrschenden Umgebungsfaktoren eine Auswirkung auf die Rekonstruktionsgüte.

Um die Auswirkung der Umgebungsfaktoren, auch Einflussfaktoren genannt, auf die Rekonstruktionsgüte zu quantifizieren wurde in dieser Arbeit eine modular aufgebaute Metrik entwickelt. Da die Annahme besteht, dass der größte Fehler bei der 3D-Rekonstruktion durch eine fehlerhafte Trajektorie entsteht, bewertet die Metrik nur die durch den Trackingalgorithmus geschätzte Trajektorie.

Um Einflussfaktoren untereinander Vergleichen zu können und die Metrik zu validieren wurden umfangreiche Versuchsreihen am RACOON-Lab der TU München und der EPOS-Anlage des DLR durchgeführt. Dabei wurden für die Versuchsreihen nur Inspektionsszenarien betrachtet.

Im RACOON-Lab war es nicht möglich eine vollständige Referenztrajektorie zu erhalten. Daher greift die Metrik auf Circlefit-Algorithmen zurück, um eine Aussage über die Qualität der geschätzten Trajektorie ohne Referenztrajektorie zu erlauben.

Ein weiteres Augenmerk dieser Arbeit ist eine umfangreiche Beschreibung des RACOON-Labs und der EPOS-Anlage. Abschließend werden beiden HIL-Anlagen miteinander verglichen, um Teilnehmern von zukünftigen Kooperationsprojekten eine Wissensgrundlage über beide Anlagen und ihre Fähigkeiten zur Verfügung zu stellen.



Seite IV

Abstract

The prognosticated increase in space debris poses a major issue for the future of space flight. Therefore, research in the field of on-orbit servicing has intensified over the last years. The controlled approach to a target object depicts a major part of these missions. To support the control algorithms or human teleoperators in such a task, it can be helpful to record the pose and the geometry of the object digitally, to reconstruct it three-dimensionally.

For the 3D-reconstruction of unknown, uncooperative objects, a vast number of tracking and mapping algorithms is freely available. The development of a flexible softwareframework, which allows to test various tracking and mapping algorithms, was already established in a previous. It was determined that not only the algorithms, but also the prevalent surrounding factors have an effect on the reconstruction quality.

To quantify the effect of such surrounding factors, also called influence factors, a module based metric was developed in the course of this work. It is assumed that a flawed trajectory is the most detrimental influence to the 3D-reconstruction quality. Therefore, the metric only assesses the trajectory estimated by the tracking algorithm.

In order to validate the metric and compare the different influence factors among each other, comprehensive test series were conducted at the RACOON-Lab of the TU Munich and the EPOS-system of the DLR.

At the RACOON-Lab, the generation of a complete ground truth trajectory could not be realized so far. Therefore, the metric relies on circle fit algorithms to evaluate the quality of the estimated trajectory, even without a ground truth trajectory.

Special attention is paid to the comprehensive description of the RACOON-Lab and the EPOS-system. Finally, both HIL-Systems were compared with one each other, to offer participants of future cooperation projects between the DLR and the TUM a general knowledge about the abilities of the systems.



Seite V

Inhaltsangabe

1 MOTIVATION 1

2 STAND DER TECHNIK 3

2.1 Trackingalgorithmen 4

2.2 Metriken für die Bewertung von Trackingalgorithmen 4 2.2.1 Absolute Trajectory Error 4 2.2.2 Relative Pose Error 6

2.3 Entwickeln einer aussagekräftigen Metrik ohne Referenz? 6

3 AUFGABENSTELLUNG 8

3.1 Szenariobeschreibung 8

3.2 Ziele der Arbeit 9

3.3 Vorgehensweise 10

3.4 Abgrenzung 11

4 ENTWICKLUNG DER METRIK 12

4.1 Anforderungen an die Metrik 12

4.2 Grundgedanke 12 4.2.1 Begriffserklärung 13

4.3 Mathematische Grundlage der Metrik 15 4.3.1 Berechnung eines angepassten Kreises für eine 3D-Punktwolke 16 4.3.2 Berechnung der Elevation zur Referenzebene 21 4.3.3 Berechnung des durchschnittlichen Residuums 21 4.3.4 Berechnung des Drifts 22 4.3.5 Abweichung von Radius und Zentrum 24

4.4 Implementierung in MATLAB 24 4.4.1 Ausführungs- und Hauptfunktion 26 4.4.2 Implementierung und Auswahl des Circlefit-Algorithmus 26 4.4.3 Ermittlung der Referenzebene im Kamera-KS 27 4.4.4 Bestimmung des nächsten Punktes auf dem Bestfit-Kreis 27 4.4.5 Herausforderungen bei der Bestimmung des Drifts 27

5 VALIDIERUNG DER METRIK 30

5.1 RACOON-Lab 30 5.1.1 Überblick 30 5.1.2 Satelliten-Mockup 36



Seite VI

5.1.3 Sensoren 36 5.1.4 Lichtquellen und Umgebung 39

5.2 EPOS 41 5.2.1 Überblick 41 5.2.2 Satelliten-Mockup 48 5.2.3 Sensoren 48 5.2.4 Lichtquellen und Umgebung 51

5.3 Vergleich der Anlagen 52 5.3.1 Komplexität 53 5.3.2 Integrierbarkeit neuer Systeme 53 5.3.3 Mockup Form und Materialien 54 5.3.4 Lichtverhältnisse 55 5.3.5 Genauigkeit 55 5.3.6 Fazit 56

5.4 Versuchsdurchführung an beiden Anlagen 57 5.4.1 Vorversuchsreihe 57 5.4.2 Hauptversuchsreihe 58

6 VERSUCHSAUSWERTUNG 65

6.1 Ergebnisse der Hauptversuchsreihe 65 6.1.1 Distanz zum Target 66 6.1.2 Winkelgeschwindigkeit des Targets 66 6.1.3 Art der Lichtquelle 68 6.1.4 Lichteinfallwinkel und Lage des Targets 69 6.1.5 Versuch an der EPOS-Anlage 70

6.2 Interpretationsansatz und Fazit 70

7 DISKUSSION 74

7.1 Die Metrik als Analysetool 74

7.2 Kritische Betrachtung der Versuche 75

8 ZUSAMMENFASSUNG DER ARBEIT 76

9 AUSBLICK 77

A LITERATURVERZEICHNIS 78

B ANHANG 81

B.1 Ergebnisse Hauptversuchsreihe 81



Seite VII

Abbildungsverzeichnis

Abb. 2–1: Durch DIFODO errechnete Relativtrajektorie zwischen Servicer (ZED Kamera) und Target. .................................................................... 3

Abb. 2–2: Bewegungstracking auf Marsuntergrund mit Merkmalspunkten, entnommen aus [12] ............................................................................. 4

Abb. 2–3: Darstellung des ATE in Rot eingezeichnet als Abstand zwischen entsprechenden Punkten auf wahrer Trajektorie und geschätzter Trajektorie, entnommen aus [7] ............................................................. 6

Abb. 3–1: Koordinatensysteme im RACOON-Lab ................................................. 8

Abb. 3–2: Rekonstruktion nach kompletter Umdrehung, aufgenommen mit der ZED ............................................................................................... 11

Abb. 4–1: Drift visualisiert durch SF mit ZED RGB-D Datensätzen. Links ist Rekonstruktion nach 100 Bildern (3 Sekunden) zu sehen. Rechts ist nach 1000 Bildern (30 Sekunden) zu erkennen, wie die Solarzelle an falscher Stelle (rot markiert) rekonstruiert wird. ............. 14

Abb. 4–2: Driftwinkels δ, der ein „Voreilen“ (links) der geschätzten Trajektorie (rot) oder ein „Hinterherhinken“ (rechts) der geschätzten Trajektorie gegenüber Punkten der wahren Trajektorie (blau). ................................................................................ 14

Abb. 4–3: Bestfit-Kreis für die Punktwolke in 2D ................................................. 20

Abb. 4–4: Bestfit-Circle K in Orange und Punktwolke der geschätzten Trajektorie in Blau. .............................................................................. 21

Abb. 4–5: Winkel Vektoren und Punkte für die Berechnung von δi...................... 23

Abb. 4–6: KS Aufteilung durch arctan2; Darstellung links aus [23] und rechts abgeändert aus [24].................................................................. 23

Abb. 4–7: Programmablaufplan der Metrik .......................................................... 25

Abb. 4–8: Verlauf des Winkels αi von Versuch Nr. 9 (Tab. 5–11). Links für den mathematisch positiven Fall und rechts für den mathematisch negativen Fall. .............................................................. 28

Abb. 4–9: αi für Versuch Nr. 9 nachdem für Werte kleiner als Null 360 ° addiert wurden .................................................................................... 28

Abb. 4–10: Links δi mit Ausreißern. Rechts δi ohne Ausreißer für Versuch Nr. 8. ................................................................................................... 29

Abb. 5–1: Konzeptzeichnung des RACOON-Lab, entnommen aus [28].............. 30

Abb. 5–2: Hauptfenster der Benutzeroberfläche des SF. Aufnahme von Kinect v2. ............................................................................................ 31

Abb. 5–3: Achsen des Boxfilters, abgeändert entnommen aus [31] .................... 33

Abb. 5–4: Anwendung eines kubischen Filters auf RGB- und Tiefenbilder der Kinect v2 entnommen aus [31]. Links oben ist das RGB-Bild



Seite VIII

unbearbeitet und rechts oben mit Boxfilter, links unten das Tiefenbild unbearbeitet und rechts unten mit Boxfilter dargestellt. ...... 33

Abb. 5–5: Visualisierungsfenster der Benutzeroberfläche des SF. Rekonstruktion aus RGB-D Bildern der Kinect v2 ............................... 34

Abb. 5–6: Freiheitsgrade (engl.: Degrees of Freedom, DoF) der Anlage entnommen aus [31] ........................................................................... 35

Abb. 5–7: Mockup aus isometrischer Ansicht (links) und Mockups aus seitlicher Ansicht (rechts). ................................................................... 36

Abb. 5–8: Servicer Struktur mit den beiden Kamera Sensoren und dem Sensorcomputer .................................................................................. 37

Abb. 5–9: Microsoft Kinect v2 RGB-D-Kamera [35] ............................................. 38

Abb. 5–10: ZED Stereokamera von Stereolabs [38] .............................................. 38

Abb. 5–11: Links zu sehen ist der Sonnensimulator des RACOON-Labs, entnommen aus [31], und rechts seine Spektralverteilung verglichen mit der Spektralverteilung der Sonne [40]. ......................... 40

Abb. 5–12: Spektralverteilung des Albedo-Simulators verglichen mit verschiedenen Referenzwerten. .......................................................... 41

Abb. 5–13: EPOS Anlage mit Scheinwerferlicht. ................................................... 42

Abb. 5–14: Aufbau der EPOS Anlage entnommen und abgeändert aus [44]. ....... 42

Abb. 5–15: Die drei verschiedenen Steuerungsebenen der EPOS-Anlage entnommen aus [43]. .......................................................................... 43

Abb. 5–16: FMC Benutzeroberfläche für Überwachung und Kontrolle der Simulation, entnommen aus [43]. ........................................................ 44

Abb. 5–17: Visualisierung der Roboterbewegung entnommen aus [43]. ............... 44

Abb. 5–18: KS der Anlage: TCS links; BCS mittig; GLCS rechts. Entnommen aus [44] ............................................................................................... 45

Abb. 5–19: IJT entnommen aus [43]...................................................................... 45

Abb. 5–20: MCU steht im Kontrollraum der Anlage zur Verfügung. ...................... 47

Abb. 5–21: Aktuelles Mockup der EPOS-Anlage ................................................... 48

Abb. 5–22: Sensorboard des Servicers der EPOS-Anlage .................................... 49

Abb. 5–23: Prosilica GC-655M entnommen aus [44] ............................................ 49

Abb. 5–24: Beispiel eines Bildes aufgenommen von der Prosilica GC-655M, in dem die Kanten erfolgreich erkannt wurden und das CAD-Modell passend darüber gelegt wurde. ............................................... 50

Abb. 5–25: Argos3D-IRS1020 DLR Prototype von Bluetechnix entnommen aus [44] ............................................................................................... 50

Abb. 5–26: Links Graustufenbild aus Intensitätswerten und rechts Tiefenbild aus Tiefenwerten der PMD-Kamera. Aufnahme aus 4 m Entfernung. .......................................................................................... 51



Seite IX

Abb. 5–27: Spektralverteilung (rechts) der ARRIMax18/12 (Scheinwerfer links) aus 7 m und 10 m Entfernung, entnommen aus [43]. ETR ASTM E-490 als Referenz. .................................................................. 52

Abb. 5–28: Draufsicht-Skizze des RACOON-Labs. ............................................... 60

Abb. 5–29: Drift von Versuch Nr. 9 ohne (links) und mit (rechts) Boxfilter. ............ 63

Abb. 6–1: Trajektorie und Bestfit-Kreis von Versuch Nr. 4 (links) und Versuch Nr. 8 (rechts). ........................................................................ 66

Abb. 6–2: Geschätzte Trajektorie und Bestfit-Kreis (links) und Drift (rechts) von Versuch Nr. 17. ............................................................................ 67

Abb. 6–3: Oben links: Residuen von Versuch Nr. 14. Oben rechts: Drift von Nr. 14. Unten links: Residuen von Versuch Nr. 18. Unten rechts: Residuen von Versuch Nr. 18. ............................................................ 68

Abb. 6–4: Verlauf von dmin für Versuch Nr. 9 links und Versuch Nr. 13 rechts. ................................................................................................. 68

Abb. 6–5: Drift von Versuch Nr. 1 links und Drift von Versuch Nr. 9 rechts. ........ 69

Abb. 6–6: Links ist Verlauf des Driftwinkels und rechts Verlauf von ΔD für Versuch Nr. 5 abgebildet. .................................................................... 71

Abb. 6–7: Von links nach rechts Tiefenbilder 1513,1555,1615,1637 der seitlichen Ansicht des Versuchs Nr. 5. ................................................ 71

Abb. 6–8: Links ist der Verlauf des Driftwinkels und rechts der Verlauf von ΔD100 für Versuch Nr. 9 abgebildet. ..................................................... 72



Seite X

Tabellenverzeichnis

Tab. 3–1: Einflussfaktoren ................................................................................... 10

Tab. 4–1: Anforderungen an die Metrik ............................................................... 12

Tab. 5–1: Bewegungsreichweite des RACOON-Labs aufgeschlüsselt entlang der Freiheitsgrade teilweise übernommen aus [32] und nachgemessen. ................................................................................... 35

Tab. 5–2: Beschreibung der Computerkomponenten des Sensorcomputers entnommen aus [31] . ......................................................................... 37

Tab. 5–3: Technische Daten der Kinect v2, entnommen aus [4, 31, 36, 37] ....... 38

Tab. 5–4: Technische Daten der ZED entnommen aus [31, 36, 38] ................... 39

Tab. 5–5: Definition der Parameter für asynchrones Kommandieren, entnommen aus [43] ........................................................................... 46

Tab. 5–6: Bewegungsreichweiten und Fähigkeiten der EPOS-Anlage dargestellt im globalen KS entnommen aus [44] ................................. 47

Tab. 5–7: Technische Daten der Argos3D-IRS1020 DLR entnommen aus [46–49] ................................................................................................ 51

Tab. 5–8: Vergleichstabelle der beiden Anlagen ................................................. 57

Tab. 5–9: Intrinsische Kameraparameter verwendeter Sensoren ....................... 58

Tab. 5–10: Weitere konstante Kameraparameter ................................................. 59

Tab. 5–11: Aufbau der Hauptversuchsreihe an RACOON und EPOS .................. 61

Tab. 5–12: Konfiguration jeder Achse (A) von Servicer (Se),Target (T) und Sonnensimulator (S) bei Versuch Nr. 1 (V1), Nr. 3 (V3), Nr. 4 (V4) und Nr. 10 (V10) .......................................................................... 62

Tab. 5–13: Verwendeter Boxfilter für Versuche ..................................................... 63

Tab. 6–1: Parameter der der Metrik für jeden Versuch der Hauptversuchsreihe auf 3 Nachkommastellen gerundet. .................... 65

Tab. 6–2: Kernaussagen der Hauptversuchsreihe .............................................. 72

Tab. 6–3: Übersicht über Erfüllung der Anforderungen an die Metrik ................. 73



Seite XI

Symbole und Formelzeichen

Im Folgenden werden nur die Symbole aufgeführt, welche eine signifikante Bedeutung für die Metrik besitzen:

𝑪𝐺 Referenzmittelpunkt des Targets

𝑪𝐾 Mittelpunkt des Bestfit-Kreises

𝐶𝐹 Distanz zwischen CG und CK

𝑟𝐹 Radiusfehler

𝑲𝑖 Punkt auf Bestfitkreis zum Zeitpunkt i

𝑷𝑖 Punkt auf Punktwolke zum Zeitpunkt i

𝛿𝑖,𝑚𝑎𝑥 Maximaler Driftwinkel

𝛿𝑖 Driftwinkel zum Zeitpunkt i

𝑅 Durchschnittliches Residuum

𝑫 Driftvektor

𝑰 Einheitsmatrix

휀 Elevation

𝒏𝐾 Normaleinheitsvektor des Bestfit-Kreises

𝒅𝑚𝑖𝑛 Die geringsten Abstände der Punkte Pi zu den nächsten Punkten Ki

In dieser Arbeit wird Folgende Notation verwendet:

𝑨 Entspricht einem Vektor oder einer Matrix

𝐴 Entspricht einem Skalar

||𝑨|| Entspricht der euklidischen Norm, welche in Fachliteratur auch mit ||A||2

gekennzeichnet wird.

|𝐴| Entspricht dem Betrag von A. Für eine Zahle A ist:

|𝐴| = {𝐴, 𝑓𝑎𝑙𝑙𝑠 𝐴 ≥ 0

−𝐴, 𝑓𝑎𝑙𝑙𝑠 𝐴 < 0

⟨𝑨, 𝑩⟩ Entspricht dem Skalarprodukt der Vektoren A und B

𝑨𝑩 Entspricht dem Vektor von Punkt A zu Punkt B



Seite XII

Abkürzungen

2D Zweidimensional

3D Dreidimensional

ACS Application Control System

API Application programming interface

ATE Absolute trajectory error

CCD Charge coupled device

DLR Deutsches Zentrum für Luft- und Raumfahrt

DoF Degree of Freedom

EPOS European Proximity Operations Simulator

FMC Facility Monitoring and Control

Fps Frames per second

GNC Guidance Navigation and Control

HIL Hardware-in-the-Loop

ICP Iterative Closest Point

IJT Ideal Joint Coordinate System

IR Infrarot

KCP Kuka Control Panel

KS Koordinatensystem

LEO Low Earth Orbit

LIDAR Light Detection and Ranging

LRC Local Robot Control

LRT Lehrstuhl für Raumfahrttechnik

MLI Multi Layer Insulation

OOS On Orbit Servicing

PMD photonic mixer device

RACOON-Lab Robotic Actuation and On-Orbit Navigation Laboratory

RB Institut für Raumflugbetrieb und Astronautentraining

RGB-D Red Green Blue-Depth

rot Rotatorisch

RPE Relative pose error

RvD Rendezvous and Docking



Seite XIII

SDK Software Development Kit

SF Softwareframework

SLAM Simultaneous Localization and Mapping

ToF Time of Flight

trans Translatorisch

TUM Technische Universität München

VI Virtual Interface

Motivation

Seite 1

1 Motivation

Mehrere Studien ergaben, dass die Anzahl an Weltraummüllteilchen der Kategorie >10 cm in den nächsten 200 Jahren auf über 12000 im Low Earth Orbit (LEO) ansteigen wird. Jedoch, unter der Annahme, dass seit 2004 keine weiteren Raketenstarts stattgefunden haben [1]. Dieser Zuwachs ist größtenteils durch Kollision massiver Körper, wie bspw. komplette Raketenoberstufen oder nicht ansteuerbare, ausgediente Satelliten zu erklären [1]. Um zu verhindern, dass es zu weiteren Kollisionen kommt, müssen diese unkontrollierbaren Körper beseitigt, oder im Falle von ausgedienten Satelliten, wieder nutzbar gemacht werden. Mit diesem in der Praxis hochkomplexen Forschungsfeld, bekannt als On Orbit Servicing (OOS), beschäftigen sich unter anderem die Technische Universität München (TUM) sowie das Deutsche Zentrum für Luft- und Raumfahrt (DLR) in Oberpfaffenhofen.

Beide Forschungseinrichtungen verfügen über Anlagen zur Simulation von OOS Szenarien. Der Lehrstuhl für Raumfahrttechnik (LRT) der TUM, befindet sich im Besitz des Robotic Actuation and On-Orbit Navigation Laboratory (RACOON-Lab), welcher als umfangreich ausgestatteter Hardware-in-the-Loop-Simulator (HIL-Simulator) für Rendezvous-Szenarien im Erdorbit beschrieben werden kann [2]. Auch die Einrichtung für Raumflugbetrieb und Astronautentraining (RB) des DLR betreibt einen solchen Hardware-in-the-Loop-Simulator namens European Proximity Operations Simulator (EPOS) [3].

Ein Teil der Mission bei On-Orbit-Servicing-Aufgaben besteht darin, einen teleoperierten oder autonomen Service-Satelliten (Servicer) kontrolliert an ein Objekt (z.B. ein Satellit oder ein Stück Weltraummüll) anzunähern. Dabei ist es hilfreich sowohl die Position und Lage (Tracking) als auch die Form (Mapping) des Objekts (wird in folgendem als Target bezeichnet) digital zu erfassen und darzustellen. In diesem Forschungsgebiet, werden größtenteils Light Detection and Ranging Sensoren (LIDAR) betrachtet [4]. Als kostengünstige, kompakte und energieeffiziente Alternative sollen nun kamerabasierte Systeme, wie bspw. die Microsoft Kinect v2 auf ihre Brauchbarkeit für Inspektionsszenarien (siehe 3.1) im All untersucht werden.

Eine vorherige Arbeit zu diesem Themengebiet entwickelte ein flexibles Softwareframework (SF) für das RACOON-Lab, welches ermöglicht Tracking und Mapping Algorithmen, sowie verschiedene Kamerasysteme miteinander auszutauschen und damit qualitativ auf ihre 3D-Rekonstruktionsgüte zu testen [4]. Den Anforderungen entsprechend wurde zum Tracking ein Algorithmus für visuelle Odometrie namens DIFODO [5] und für den Mapper ein Algorithmus zur volumetrischen Umgebungsrekonstruktion namens fastfusion [6] ausgewählt.

Erste Testergebnisse ergaben, dass die schwierigen Lichtverhältnisse, die im RACOON-Lab herrschen, welche gezielt die schlechten Lichtverhältnisse im Orbit simulieren sollen, eine merkbare Verschlechterung der Rekonstruktionsgüte hervorrufen [4]. Um quantitativ feststellen zu können, welchen Einfluss die Lichtverhältnisse oder andere Einflussparameter (siehe 3.3) auf die Rekonstruktionsgüte besitzen, soll im Zuge dieser Bachelorarbeit ein Analysetool in Form einer Metrik entwickelt werden.

Unter der Annahme, dass der größte Fehler bei der 3D-Rekonstruktion in der Trajektorie liegt, welche durch den eingesetzten Tracking Algorithmus geschätzt wird,

Motivation

Seite 2

beschränkt sich die Metrik auch nur auf die Bewertung dieser. Die Entwicklung sowie die Implementierung der Metrik in MATLAB, wird in Kapitel 4 genauer beschrieben. Des Weiteren werden in Kapitel 2 alternative, bereits bewährte Möglichkeiten zur quantitativen Bewertung von geschätzten Trajektorien kurz vorgestellt und darüber hinaus erläutert, warum diese nicht als Analysetool für das Softwareframework verwendet wurden.

Die Validierung der Metrik erfolgt in mehreren Testreihen, die am RACOON-Lab oder dem EPOS durchgeführt wurden. Der Versuchsaufbau wird in 5.4 genauer beschrieben und die Ergebnisse der Testreihen sind in Kapitel 6 zu finden und werden in Kapitel 7 diskutiert. Des Weiteren wurden die Unterschiede der beiden Anlagen in Bezug auf verschiedene Aspekte, wie bspw. die Komplexität der Anlage, in einem Vergleich erarbeitet. Dieser ist in 5.3 dokumentiert. Ermöglicht wurde dieser Wissensaustausch durch einen zweimonatigen Aufenthalt beim DLR in Oberpfaffenhofen. Durch dieses gemeinsame Projekt soll ein erster Schritt in Richtung Zusammenarbeit des LRT mit der Einrichtung für Raumflugbetrieb und Astronautentraining im Forschungsgebiet OOS erfolgen.

Abschließend gibt Kapitel 8 eine Zusammenfassung der gesamten Arbeit und Kapitel 9 einen Ausblick auf nächste Schritte, sowie mögliche zukünftige Projekt auf dem Weg zu einer umfassenden Lösung zur korrekten Lageschätzung und letztendlich 3D-Rekonstruktion eines unbekannten Objekts, im Rahmen der teleoperierten oder autonomen Nahbereichsnavigation, im Orbit.

Stand der Technik

Seite 3

2 Stand der Technik

In diesem Kapitel werden bewehrte Metriken für die quantitative Bewertung von erdgebundenen Tracking-Szenarien betrachtet. Da es dabei rein um die Auswertung der geschätzten Trajektorie geht, können diese Metriken problemlos auf OOS-Szenarien übertragen werden. Auf den aktuellen Stand der Technik von RGB-D bzw. Stereovision Kamerasysteme wird hierbei nicht eingegangen. Technische Details zu den verwendeten Kamerasystemen (Kinect v2, ZED und PMD) werden in Kapitel 5 gegeben.

Die Trajektorie, welche von einem Trackingalgorithmus errechnet wird, beschreibt die Lage der Kamera relativ zum Target in einem kamerafixen Koordinatensystem (KS). Eine geschätzte Trajektorie einer einfachen Kreisbewegung um das betrachtete Objekt ist in Abb. 2–1 dargestellt. Diese erste grobe Beschreibung des Szenarios dient lediglich dem Verständnis. Eine genauere Beschreibung des Szenarios folgt in Kapitel 3.

Abb. 2–1: Durch DIFODO errechnete Relativtrajektorie zwischen Servicer (ZED Kamera) und Target.

Qualitativ ist zu erkennen, dass die geschätzte Trajektorie, die eine 360 ° Umdrehung darstellen soll, fehlerhaft ist. Um jedoch eine quantitative Aussage über die Größe des Fehlers zu treffen, müssen verschiedene Bewertungsverfahren betrachtet werden. Bei zwei der verbreiteteren Methoden wird der absolute Fehler der Trajektorie (engl.: Absolute Trajectory Error, ATE) und der relative Lagefehler (engl.: Relative Pose Error, RPE) der Trajektorie errechnet [7]. Für beide Methoden ist der Zeitstempel, die Position und die Lage jedes Punktes auf der geschätzten Trajektorie, sowie auf der Referenztrajektorie (engl.: Groundtruth) zur Berechnung des Fehlers nötig. Beispiele für die Verwendung der ATE-Methode sind in [7, 8] und für die Verwendung der RPE-Methode in [7] zu finden.

Im Folgenden werden zunächst die grundlegenden Funktionsprinzipien des verwendeten Trackingalgorithmus überblicksartig vorgestellt. Im Anschluss werden die beiden Methoden zur Ermittlung des Fehlers der Trajektorie erläutert. Für genaue Informationen zu beiden Methoden sei auf [7] verwiesen.

Stand der Technik

Seite 4

2.1 Trackingalgorithmen

Algorithmen zur Lageschätzung von RGB-D-Kameras werden unter dem allgemeinen Begriff „visuelle Odometrie“ [9] zusammengefasst. Dabei wird die Bewegung der Kamera zwischen den beiden Aufnahmepositionen aus den aufeinanderfolgenden Farb- und Tiefenbildern geschätzt [4]. Die meisten Methoden in diesem Bereich arbeiten dabei mit einzelnen Merkmalspunkten, die aus den Bildern extrahiert werden und zwischen denen Korrespondenzen ermittelt werden [4, 10]. Die Korrespondenzen zwischen den einzelnen Merkmalspunkten werden dabei meist über Varianten des ICP-Algorithmus (Iterative Closest Point, [11]) ermittelt, welcher versucht zwei dünnbesetzte Punktwolken möglichst gut übereinanderzulegen. Die nötige Transformation zwischen den Punktwolken beschreibt die zugehörige Kamerabewegung, welche in Abb. 2–2 zu sehen ist [4]. Dadurch kann bei Anwendung auf größere Bildabfolgen die Bewegung der Kamera und damit die von der Kamera beschriebene Trajektorie ermittelt werden. Da die Algorithmen im Bereich visuelle Odometrie ursprünglich für Mono- und Stereo-Kamerasysteme entwickelt wurden, eignen sie sich nicht nur für die Kinect v2 (RGB-D Sensor), sondern ebenfalls für die ZED (Stereovision Kamera) [4].

Abb. 2–2: Bewegungstracking auf Marsuntergrund mit Merkmalspunkten, entnommen aus [12]

DIFODO ist ebenfalls ein Algorithmus der visuellen Odometrie [5] und der Trackingalgorithmus der momentan im Softwareframework implementiert ist. Der DIFODO-Algorithmus wurde für sämtliche Versuche dieser Arbeit verwendet. Er verwendet nur die Tiefenbilder der Kameras um deren Lage relativ zum Betrachtungsobjekt zu schätzen. Der Algorithmus verfügt über keine Funktionalitäten, um den Drift der Lageschätzung über die Zeit zu minimieren, wie beispielsweise Graph-Optimierung oder Schleifenerkennung [4].

2.2 Metriken für die Bewertung von Trackingalgorithmen

2.2.1 Absolute Trajectory Error

Die ATE-Methode zeichnet sich damit aus, eine klare Aussage bezüglich der Qualität der errechneten Trajektorie zu gewähren. Zusammengefasst berechnet sie den Mittelwert der euklidischen Distanzen zwischen den entsprechenden Punkten der wahren und der geschätzten Trajektorie. Es muss jedoch sichergestellt werden, dass

Stand der Technik

Seite 5

für jeden Punkt auf der errechneten Trajektorie ein Punkt auf der Referenztrajektorie mit dem entsprechenden Zeitstempel vorliegt.

Es wird also angenommen, dass Lage und Position sämtlicher Punkte der geschätzten Trajektorie P1, . . ., Pn ϵ SE(3) und der Referenztrajektorie Q1, . . ., Qn, ϵ SE(3) gegeben ist. SE(3) oder auch die Spezial euklidische Gruppe, ist eine Lie-Gruppe (siehe [13]). Damit beinhaltet Pi zum Zeitpunkt i einen rotatorischen Anteil R, welcher die Lage des starren Körpers angibt und einen translatorischen Anteil r, welcher die Position in kartesischen Koordinaten angibt:

𝑷𝑖 = [𝑹 𝒓

𝟎1×3 1] 𝑚𝑖𝑡 𝑹 ∈ ℝ3×3, 𝒓 ∈ ℝ3 𝑢𝑛𝑑 𝑹𝑇𝑹 = 𝑹𝑹𝑇 = 𝑰 ( 2–1 )

Sowohl Qi als auch Pi besitzen die gleiche Länge n und sind zeitlich synchron [7]. Da sich die beiden Trajektorien in willkürlichen Koordinatensystemen befinden können, müssen diese zuerst aneinander angepasst werden. Dies kann in geschlossener Form, beispielsweise mit der Horn-Methode [14] erreicht werden, welche die Starrkörpertransformationsmatrix S mit Hilfe der Methode der kleinsten Quadrate, findet [7]. Diese Transformation erlaubt nun den absoluten Fehler der Trajektorie zum Zeitpunkt i zu berechnen:

𝑭𝑖 = 𝑸𝑖−1𝑺𝑷𝑖 ( 2–2 )

In [7] wird weiterhin vorgeschlagen den mittleren quadratischen Gesamtfehler (engl.: Root Mean Square Error, RMSE) über alle Zeit Indices der translatorischen Komponenten zu evaluieren:

𝑅𝑀𝑆𝐸(𝑭𝑖:𝑛) ≔ (1

𝑛∑ ||𝑡𝑟𝑎𝑛𝑠(𝑭𝑖)||

2𝑛𝑖=1 )

1

2 ( 2–3 )

Dabei bezieht sich trans(Fi) nur auf die translatorischen Komponenten des absoluten Fehlers Fi. Der RMSE gewichtet größere Werte stärker als kleinere Werte oder Nullen. Dies kann für die Auswertung bestimmter Versuche von Vorteil sein. An dieser Stelle, kann jedoch auch der Durchschnittswert oder der Median statt dem RMSE berechnet werden, um den Einfluss von Ausreißern zu verringern. Praktisch gesehen bietet die ATE-Methode eine intuitive Visualisierung, welche über die Zeit oder entlang der verwendeten Achsen (siehe Abb. 2–3) dargestellt werden kann.

Stand der Technik

Seite 6

Abb. 2–3: Darstellung des ATE in Rot eingezeichnet als Abstand zwischen entsprechenden Punkten auf wahrer Trajektorie und geschätzter Trajektorie, entnommen aus [7]

2.2.2 Relative Pose Error

Die RPE-Methode, ebenfalls von [7] vorgestellt, eignet sich besonders für die Evaluation von Systemen der visuellen Odometrie. Sie berechnet die Genauigkeit der Trajektorie über ein fixes Zeitintervall Δ [7]. Der errechnete relative Lagefehler entspricht dabei dem sogenannten „Drift“ der Trajektorie. Der relative Lagefehler zum Zeitpunkt i ist definiert als:

𝑬𝑖 = (𝑸𝑖−1𝑸𝑖+𝛥)−1(𝑷𝑖

−1𝑷𝑖+𝛥) ( 2–4 )

Für n Kamera Positionen erhält man somit m=n-Δ verschiedene relative Lage Fehler. Bei einem Zeitintervall Δ=1 bedeutet dies, dass jeder Zeitpunkt mit dem vorherigen verrechnet wird und somit m=n-1 verschiedene relative Lage Fehler erhalten werden können. Auch hierbei wird in [7] vorgeschlagen den RMSE über alle Zeit Indices wie folgt zu berechnen:

𝑅𝑀𝑆𝐸(𝑬1:𝑛, 𝛥) ≔ (1

𝑚∑ ||𝑡𝑟𝑎𝑛𝑠(𝑬𝑖)||

2𝑚𝑖=1 )

1

2 ( 2–5 )

Diese Metrik berücksichtigt den translatorischen, sowie den rotatorischen Fehler und fällt damit meistens größer (oder gleich groß, falls es keinen rotatorischen Fehler gibt) als der ATE aus. Es ist jedoch nicht abzustreiten, dass jeder translatorische Fehler mit einem rotatorischen Lagefehler zusammenhängt.

2.3 Entwickeln einer aussagekräftigen Metrik ohne Referenz?

Das Problem der beiden beschriebenen Methoden für die Anwendung im RACOON-Lab ist die Notwendigkeit einer zuverlässigen Referenztrajektorie. Diese kann beispielweise durch Motion-Capture-Systeme oder mit CAD gestützten

Stand der Technik

Seite 7

Lageschätzungs-Algorithmen (siehe 5.2.3.1) gewonnen werden. Mit OptiTrack stand ein Motion-Capture-System erst zum Ende dieser Arbeit zur Verfügung. Es war jedoch nicht möglich eine vollständige Referenztrajektorie zu erhalten, sondern lediglich die Position verschiedener markierter Reflektoren im Raum.

Dieser limitierende Faktor spielte eine erhebliche Rolle bei der Entwicklung dieser Metrik und stellt somit eine primäre Anforderung an die Metrik dar (siehe 4.1).

Es existieren bereits Metriken, die ohne Referenz den intrinsischen Fehler nach der Abbildung-Optimierung (engl.: map optimization) oder allgemein den χ2 Fehler berechnen. Jedoch garantiert ein niedriger χ2 Wert weder eine „gute“ Abbildung (wird im Zuge von SLAM durch Mapping-Algorithmen rekonstruiert) [15], noch eine Trajektorie die der Referenztrajektorie entspricht [7]. Um also eine Metrik zu entwickeln die ohne Referenz eine quantifizierbare Aussage über die Qualität der Trajektorie erlaubt, wurden Einschränkungen für die Anwendbarkeit dieser festgelegt. Eine Entscheidende Einschränkung verlangt, dass die Referenztrajektorie einen Kreis oder ein Kreissegment darstellt. Dies erlaubt die Generierung einer angepassten Kreistrajektorie, welche für diese Metrik als Referenz benutzt wird. Nach diesem ersten groben Überblick über das Prinzip, wird in Kapitel 3 das Szenario beschrieben auf das die Metrik angewendet werden kann und in Kapitel 4 der mathematische Grundgedanke bis hin zur Implementierung in MATLAB behandelt.

Aufgabenstellung

Seite 8

3 Aufgabenstellung

3.1 Szenariobeschreibung

Für die quantitative Bewertung von Trackingalgorithmen oder Einflussfaktoren mit Hilfe einer Metrik, ist eine simple und doch realitätsnahe Testkampagne notwendig. Um einen schnell reproduzierbaren Versuchsaufbau zu erhalten, wurde ein einfaches und dennoch möglichst realistisches Szenario im Rahmen der Nahbereichsnavigation im OOS gewählt. Da die Annahme besteht, dass das zu rekonstruierende Objekt unbekannt und unkooperativ ist, sollte zunächst ein Inspektionsmanöver von einem Service-Satelliten (im Folgenden als Servicer bezeichnet) geflogen werden. Unkooperativ bedeutet in diesem Fall, dass das Objekt weder präpariert (bspw. mit speziellen Reflektoren) wurde, noch kontrollierbar ist. Um eine vollständige 3D-Rekonstruktion des betrachteten Objektes (im Folgenden als Target bezeichnet) zu gewährleisten, sollten die verwendeten RGB-D Kamerasysteme ein Bild des Targets von jedem Winkel einer Kreisbahn aus aufnehmen. Da das betrachtete Objekt unbekannt ist, wird die entstandene 3D-Darstellung nicht mit einem Fitting von 3D-CAD-Modellen oder ähnlichem weiter verarbeitet [4]. Das simulierte Szenario ist somit stets eine vollständige Kreisbahn des Servicers relativ zum Target mit konstantem Abstand und konstanter Winkelgeschwindigkeit. Realisiert wird dies durch eine konstante Drehung des Targets um die Gier-Achse im RACOON-Lab und in der EPOS-Anlage. Dabei wird der Ursprung des Kamera-KS stets auf den Mittelpunkt des Targets ausgerichtet. Somit befindet sich das Target zu jedem Zeitpunkt vollständig im Sichtfeld der Sensoren. Daher ist es nicht nötig die Lage des Servicers zu bewerten, da dieser statisch ist und weder Lage noch Position ändert. Die Oberflächenbeschaffenheit sowie die äußere Form des Targets entsprechen in beiden Anlagen der eines generischen Target-Satelliten. Genauere Angaben zum Mockup des RACOON-Labs und der EPOS-Anlage sind in 5.1.2 und 5.2.2 zu finden. Da ein Großteil der Versuchsreihe am RACOON-Lab durchgeführt wurde, wird dieses zur weiteren Szenariobeschreibung herangezogen.

Abb. 3–1: Koordinatensysteme im RACOON-Lab

Aufgabenstellung

Seite 9

In Abb. 3–1 ist zu erkennen, dass drei verschiedene Koordinatensysteme im RACOON-Lab verwendet werden. Ein Kamera-KS im spezifischen Zentrum des verwendeten Sensors. Das globale Anlagen-KS und das KS des OptiTrack Systems (siehe 5.1). Insgesamt stehen dem Operator somit elf Freiheitsgrade für das Verfahren von Servicer und Target zur Verfügung. Realistische Lichtverhältnisse werden durch einen Molton-Vorhang, einen Sonnensimulator [16] und einen Erdalbedo-Simulator erzeugt. Für den Versuch soll nun immer ein Einflussfaktor (bspw. die Distanz oder die Neigung) variiert werden und somit auf seine Auswirkung auf die Rekonstruktionsgüte untersucht werden (siehe 5.4). Genauere Information zum Aufbau beider Anlagen ist in Kapitel 5 zu finden.

3.2 Ziele der Arbeit

Das übergeordnete Ziel der Arbeit ist es den Einfluss bestimmter Umgebungsfaktoren, bei teleoperativen oder autonomen Aufgaben im Rahmen der Nahbereichsnavigation des OOS, auf die Rekonstruktionsqualität quantitativ zu bewerten. Dafür wurde eine experimentelle Studie an zwei Hardware-in-the-loop Anlagen, welche erlauben das in Kapitel 3.1 beschriebene Szenario darzustellen, durchgeführt.

Um die quantitative Bewertung der Testergebnisse zu ermöglichen, soll eine flexible Metrik entwickelt werden. Darüber hinaus soll die Metrik als Bewertungskriterium und Analysetool für die eingesetzten Sensorsysteme, Trackingalgorithmen und Einflussfaktoren fungieren.

Die Ergebnisse der Analyse sollen interpretiert und wenn möglich mit bestimmten Einflussfaktoren (bspw. Umdrehungsgeschwindigkeit, Lichtverhältnisse) assoziiert werden. So soll es möglich sein eine Aussage darüber zu treffen, welche Auswirkung bestimmte Einflussparameter, wie bspw. schlechte Lichtverhältnisse, auf welche Qualitätsmerkmale, festgelegt durch die Metrik, besitzen.

Ein weiteres Ziel der Arbeit besteht darin, eine Kooperation und damit einen stetigen Wissensaustausch zwischen der Einrichtung für Raumflugbetrieb und Astronautentraining und dem Lehrstuhl für Raumfahrttechnik zu etablieren. Dabei soll für im Rahmen dieser Arbeit ein Vergleich der beiden OOS Simulationsanlagen durchgeführt und dokumentiert werden (siehe 5.3). So kann bei zukünftigen Projekten festgestellt werden, welche Anlage sich besser für das ausgewählte Szenario eignet.

Außerdem bestand durch die EPOS Anlage eine Möglichkeit die Metrik in einer weiteren Versuchsumgebung zu validieren. Hierbei sollte nicht die absolute Qualität der aus den Tiefenbildern der PMD Kamera errechneten Trajektorie bewertet werden, sondern lediglich die Anwendbarkeit des Softwareframeworks [4] und der Metrik auf verschiedene Systeme.

Das langfristige über diese Arbeit hinausgehendes Ziel ist es, durch weitere gemeinsame Projekte, die Vorteile beider Anlagen für Experimente der Nahbereichsnavigation des OOS zu nutzen und die Metrik bei bestimmten Szenarien als Analysetool zur Verfügung zu haben.

Aufgabenstellung

Seite 10

3.3 Vorgehensweise

Nachdem in vorherigen Testkampagnen die Auswirkung der Lichtverhältnisse auf die Rekonstruktionsgüte festgestellt wurde, kam die Frage auf, welche weiteren Einflussfaktoren gravierende Auswirkungen auf die Rekonstruktionsgüte haben könnten. Daher wurden im Laufe dieser Arbeit zunächst sämtliche möglichen Einflussfaktoren zusammengestellt, um dann eine engere Auswahl an Einflussfaktoren zu definieren. Dabei wurden Einflussfaktoren ausgewählt welche sich in Laborumgebung verlässlich variieren lassen und bei denen eine deutliche Auswirkung auf die Rekonstruktionsgüte erwartet wird. In der folgenden Tabelle sind alle erarbeiteten Einflussfaktoren aufgelistet.

Tab. 3–1: Einflussfaktoren

Einflussfaktor Status

Distanz zum Target Ausgewählt für Testreihe

Winkelgeschwindigkeit des Targets Ausgewählt für Testreihe

Art der Lichtquelle Ausgewählt für Testreihe

Lichteinfallwinkel Ausgewählt für Testreihe

Lage des Targets Ausgewählt für Testreihe

Sensor Ausgewählt für Testreihe

Umdrehungsrichtung Nicht berücksichtigt

Startausrichtung gegenüber des Targets gegenüber dem Servicer

Nicht berücksichtigt

Kameraparameter/Softwareparameter: Auflösung, Bildwiederholrate (engl. Framerate), Belichtungszeit, Helligkeit, Kontrast, Sättigung, Schärfe, Weißabgleich

Nicht berücksichtigt

Zu beachten ist jedoch, dass diese Liste nicht alle möglichen Einflussfaktoren darstellt. Nicht genannte softwarespezifische Faktoren wurden für diese Testreihe nicht berücksichtigt. Umdrehungsrichtung und Startausrichtung des Targets gegenüber dem Servicer wurde für die Hauptversuchsreihe ebenfalls nicht berücksichtigt. Eine Begründung dafür ist in 5.4.1 zu finden.

Nach dem definieren der Einflussfaktoren mussten die Anforderungen an die Metrik formuliert werden, welche die Grundvorrausetzungen an eine Metrik unter den gegeben Rahmenbedingungen darstellen. Nach kurzer Einarbeitungszeit in das Softwareframework wurden Daten einiger Vorversuchsreihen qualitativ betrachtet, um die Annahme zu treffen, dass der größte Fehler bei der 3D Rekonstruktion in der Berechnung der Trajektorie liegen könnte. Um einen Überblick über aktuell verwendete Metriken zur Bewertung von Trackingalgorithmen zu erhalten, war eine Literaturrecherche notwendig. Mit dem gewonnenen Wissen wurde entschieden, dass keine der betrachteten Metriken den Anforderungen genügte und daher eine neue Metrik entwickelt werden musste. Die Implementierung der Metrik erfolgte in MATLAB um die Einarbeitungszeit in die Syntax gering zu halten und trotzdem ein umfangreiches Werkzeug, für die Entwicklung, zur Verfügung zu haben.

Um die Metrik zu validieren, erfolgten Tests an den zwei HIL-Systemen, RACOON-Lab und EPOS. Um ein fundiertes Wissen über die EPOS-Anlage zu erhalten, wurde ein zweimonatiger Austausch zum DLR organisiert. Das gewonnene Wissen soll in Form eines Vergleichs zukünftigen Projekten zur Verfügung stehen.

Aufgabenstellung

Seite 11

Mehrere Testreihen wurden durchgeführt, um die betrachteten Einflussfaktoren mit den Bewertungsparametern der Metrik zu assoziieren. So kann letztendlich eine Aussage darüber getroffen werden, welche Auswirkung bestimmte Einflussfaktoren auf die Rekonstruktionsgüte von Trackingalgorithmen besitzen.

3.4 Abgrenzung

Die Anwendung von Tracking- und Mappingalgorithmen zur 3D-Rekonstruktion von unkooperativen Objekten im Orbit ist ein noch junges Forschungsgebiet. Mit der Möglichkeit zur quantitativen Bewertung der im SF verwendeten Algorithmen, erlangt man die Fähigkeit, unter einer Vielzahl an Trackingalgorithmen die, bezogen auf ihre Rekonstruktionsgüte, geeignetsten herauszufiltern. Die Implementierung und Bewertung weiterer Algorithmen wird jedoch nicht im Rahmen dieser Arbeit behandelt werden.

Des Weiteren ist die erstellte Metrik nur in der Lage das beschriebene Szenario, welches einem vollständigen Kreis mit konstantem Abstand und Geschwindigkeit entspricht, zu bewerten. Rein translatorische Bewegungen, wie bei einem Dockingmanöver, werden in keinem Versuch betrachtet. Dabei ist die Metrik lediglich im Stande die geschätzte Trajektorie, beziehungsweise den Trackingalgorithmus zu bewerten, da hier der größte Fehler in der 3D-Rekonstruktion vermutet wird. Durch den enormen Fehler in der geschätzten Trajektorie erzeugt der Mappingalgorithmus, im Rahmen des beschrieben Szenarios, nur ein schlecht verwertbares Ergebnis, welches in Abb. 3–2 dargestellt ist. Daher, ist keine Bewertung des Mappingalgorithmus vorgesehen.

Abb. 3–2: Rekonstruktion nach kompletter Umdrehung, aufgenommen mit der ZED

Weiterhin, werden nur Auswirkungen der Einflussfaktoren auf die berechnete Trajektorie erarbeitet und keine expliziten Verbesserungsansätze, für Soft- oder Hardware, vorgestellt.

Der Aufenthalt beim DLR ermöglicht zwei konzeptionell ähnliche Anlagen miteinander zu vergleichen und gleichzeitig die Anwendungsmöglichkeiten der Metrik zu erproben. Dabei wird das Sensorsystem der EPOS-Anlage nicht quantitativ mit denen des RACOON-Labs verglichen, da sich die Testumgebung der beiden Labore zu sehr unterscheidet. Jedoch soll der Weg für zukünftige Projekte geebnet werden, die dies thematisieren könnten.

Entwicklung der Metrik

Seite 12

4 Entwicklung der Metrik

Der Hauptteil dieser Arbeit bestand in der Entwicklung einer Metrik als Analysetool für die Benutzeroberfläche des RACOON-Labs, um eine quantitative Bewertung der geschätzten Trajektorie zu ermöglichen. Nach den bereits beschriebenen Begrenzungen des Anwendungsbereichs, folgt nun ein Überblick über die Anforderungen, welche an die Metrik formuliert wurden. Anschließend wird eine kurze Zusammenfassung über den Aufbau der Metrik gegeben. Darauf folgt eine detaillierte Erläuterung der Mathematik, die der Metrik zugrunde liegt. Abschließend wird auf Probleme und Besonderheiten bei der Implementierung in MATLAB eingegangen.

4.1 Anforderungen an die Metrik

Noch bevor das Grundgerüst der Metrik verfasst wurde standen die primären Anforderungen an die Metrik fest. Darunter zählen die Anforderung Nr. 1 und Nr. 5. Im Laufe der Arbeit wurde die Liste an Anforderung jedoch erweitert. Der finale Stand der Anforderungsliste ist in Tab. 4–1 dargestellt.

Tab. 4–1: Anforderungen an die Metrik

Nr. Anforderung

1 Die Metrik soll auch ohne Referenztrajektorie eine Aussage über die Qualität der errechneten Trajektorie erlauben.

2 Darüber hinaus soll die Metrik nur mit den durch das SF und dem OptiTrack-System bereitgestellten Daten (siehe 5.1.1.1) eine Aussage über die Qualität der errechneten Trajektorie erlauben.

3 Die Metrik sollte in MATLAB oder C++ implementiert werden.

4 Da die Entwicklungsarbeit im RACOON-Lab unter Windows erfolgt, sollte auch die Metrik für den Einsatz unter Windows protierbar sein.

5 Die Metrik soll modular aufgebaut sein, um die Auswirkung der Einflussfaktoren besser zu kategorisieren und isoliert zu betrachten. Dadurch soll auch ohne Referenzpunkte eine erste Aussage über die Qualität der Trajektorie getroffen werden.

6 Die Metrik soll unabhängig von der Versuchsumgebung funktionieren und dementsprechend im RACOON-Lab und an der EPOS-Anlage einsetzbar sein.

4.2 Grundgedanke

Um die Auswirkung von SLAM-Algorithmen (Simultaneous Localization and Mapping) und Einflussfaktoren auf die Rekonstruktionsgüte zu kategorisieren sollte entsprechend Anforderung Nr. 5, eine modular aufgebaute Metrik entwickelt werden. Da keine Referenztrajektorie zur Verfügung stand, wurde mit Hilfe von sogenannten Fitting-Algorithmen eine geometrische Figur erstellt, welche der Punktwolke der Trajektorie am ähnlichsten ist und gleichzeitig mit dem gegebenen Szenario übereinstimmt. Um die Aufgabe an dieser Stelle zu vereinfachen wurde wie in Kapitel 3.1 beschrieben nur ein Inspektionsszenario betrachtet. Die betrachtete geometrische Figur ist also ein Kreis K ϵ ℝnx3 der aus n Punkten K0, …, Ki, …, Kn-1 ϵ


Seite 13

ℝ3 besteht. Dieser Kreis K kann nun betrachtet werden um verschiedene Eigenschaften der Punktewolke mit ihm zu vergleichen, oder bestimmte Eigenschaften wie den Radius oder den Mittelpunkt des Kreises mit den entsprechenden Referenzwerten, welche durch das OptiTrack-System ermittelt werden können, zu vergleichen. Damit ergeben sich fünf Module oder Parameter der Metrik welche eine quantitative Bewertung der errechneten Trajektorie ermöglichen. Die fünf Parameter sind:

• Die Distanz CF welche ermittelt werden kann, wenn Mittelpunkt CK des Kreises K mit dem Referenzwert CG verrechnet wird.

• Der Fehler des Radius rF, welcher durch die Differenz zwischen Radius rK des Kreises K und dem Referenzwert rG errechnet werden kann

• Die Elevation ε des Kreises K gegenüber der Referenzebene

• Das durchschnittliche Residuum R der geschätzten Trajektorie im Bezug auf den mit Fitting-Algorithmen errechneten Kreis K

• Der Drift D der geschätzten Trajektorie im Vergleich zu K

Die Idee besteht darin, dass wenn sämtliche Fehler, die durch die fünf Module beschrieben werden Null entsprechen, der entstandene Kreis K identisch mit der Punktwolke der geschätzten Trajektorie und letztendlich ebenfalls identisch mit der Referenztrajektorie ist. Dabei ist K selbstverständlich bereits identisch mit der Referenztrajektorie, sobald CK, rK mit den entsprechenden Referenzwerten übereinstimmen und die Elevation 0 ° entspricht.

Eine besonders wichtige Rolle unter den fünf Modulen nimmt der Drift ein. Schon bevor die Metrik verfasst wurde, bestand die Annahme, dass der Drift einen erheblichen Einfluss auf die Rekonstruktionsgüte besitzt.

Es handelt sich bei dem beschriebenen Drift jedoch nicht um den gleichen Wert der in [7] und folglich in Kapitel 2.2.2 beschrieben wird. Eine Erklärung des Begriffs und weitere Definitionen folgen im nächsten Unterkapitel.

4.2.1 Begriffserklärung

In den folgenden Kapiteln werden Begriffe verwendet, die im Kontext dieser Arbeit eine bestimmte Bedeutung zugeordnet wurde. Diese Begriffe werden kurz erläutert. Dabei kann es durchaus sein, dass diese Begriffe außerhalb dieser Arbeit, eine andere Bedeutung besitzen.

4.2.1.1 Drift

Während sämtlicher Versuche, besitzt die geschätzte Trajektorie die Eigenschaft keinen vollständigen Kreis darzustellen, sondern lediglich Kreissegmente (bspw. ein Viertel- oder Halbkreis) unterschiedlicher Ausprägung. Die einzelnen Positionen der Trajektorie hinken damit den Positionen der wahren Trajektorie hinterher. Die Position des Servicers wird also nicht korrekt relativ zum Target eingeschätzt. Darunter leidet die Rekonstruktionsfähigkeit, da Elemente des Targets, wie bspw. die Solarzellen, an falscher Stelle rekonstruiert werden. In Abb. 4–1 ist zu erkennen wie dieser Effekt über die Zeit zunimmt und die Solarzelle von ihrer ursprünglich geschätzten Position „abdriftet“.


Seite 14

Abb. 4–1: Drift visualisiert durch SF mit ZED RGB-D Datensätzen. Links ist Rekonstruktion nach 100 Bildern (3 Sekunden) zu sehen. Rechts ist nach 1000 Bildern (30 Sekunden) zu

erkennen, wie die Solarzelle an falscher Stelle (rot markiert) rekonstruiert wird.

Der Winkel δ der das „Voreilen“ oder „Hinterherhinken“ eines Punktes auf der geschätzten Trajektorie gegenüber dem entsprechenden Referenzpunkt beschreibt, wächst daher mit zunehmender Zeit an und ist in Abb. 4–2 abgebildet. Dementsprechend beschreibt der Drift D ϵ ℝn einer Trajektorie einen Vektor, der die Winkel δi zu allen Zeitpunkten i darstellt. Daher wird der Winkel δ im weiteren Verlauf als Driftwinkel bezeichnet.

Abb. 4–2: Driftwinkels δ, der ein „Voreilen“ (links) der geschätzten Trajektorie (rot) oder ein „Hinterherhinken“ (rechts) der geschätzten Trajektorie gegenüber Punkten der wahren

Trajektorie (blau).

Die Berechnung der Driftwinkel zu jedem Zeitpunkt und dem daraus resultierenden Drift D erfolgt in Kapitel 4.3.4.

4.2.1.2 Residuum

Das Residuum beschreibt in der numerischen Mathematik die Abweichung vom gewünschten Ergebnis. Es wird [17] in berechnet mit:

𝑅 = 𝒃 − 𝑨𝒙 𝑚𝑖𝑡 𝑨 ∈ ℝn×r, 𝑛 ≥ 𝑟, 𝒃 ∈ ℝn ( 4–1 )

Im Fall der Metrik gibt das Residuum die Abweichung aller Punkte der geschätzten Trajektorie zum jeweils nächsten Punkt auf dem Kreis K an.


Seite 15

4.2.1.3 Bestfit-Ebene und Bestfit-Kreis

Die Ebene, welche am besten im Sinne von Nähe, zu einer Punktwolke passt wird in dieser Arbeit als Bestfit-Ebene bezeichnet. Die Berechnung dieser wird in 4.3.1.1 thematisiert.

Ein Kreis der am besten zu einer Wolke von Punkte passt und auf der Bestfit-Ebene liegt wird in dieser Arbeit als Bestfit-Kreis bezeichnet. Die Berechnung des Kreises wird in 4.3.1.2 thematisiert.

4.2.1.4 OptiTrack

Das OptiTrack ist ein Bewegungserfassungssystem (Motion Capture System) welches von Natural Point [18] entwickelt wurde und im Zuge einer Masterarbeit von J. Otto in das RACOON-Lab implementiert wurde. Dabei erfassen acht Sensoren die die Bewegung der Reflektoren, welche nach Belieben montiert werden können. Um einen starren Körper zu erfassen müssen drei solcher Reflektoren an einem Körper befestigt sein. Mit Hilfe des OptiTrack-Systems wurden die Koordinaten sämtlicher Referenzpunkte, welche mit einem „G“ im Index gekennzeichnet sind, und die Punkte X1, X2, X3 ϵ ℝ3, im OptiTrack-KS ermittelt.

4.2.1.5 Elevation

Die Elevation beschreibt in der Astrometrie oder Geodäsie den Winkel eines Punktes über dem Horizont. Die Elevation wird auch Höhe oder Höhenwinkel genannt und ergibt addiert mit dem Zenitwinkel einen rechten Winkel. Für diese Arbeit beschreibt die Elevation den Winkel zwischen der Bestfit-Ebene der geschätzten Trajektorie und der Referenzebene. Die Referenzebene ist entweder parallel zur XZ-Ebene des OptiTrack-KS oder um 17.52 ° zu dieser geneigt (siehe 5.4.2).

4.3 Mathematische Grundlage der Metrik

Mit den verfügbaren Daten die durch den Trackingalgorithmus und dem OptiTrack-System zur Verfügung gestellt werden gilt es nun die fünf, in Kapitel 4.2, beschriebenen, Parameter gemäß der Anforderungen in Kapitel 4.1 zu berechnen. Gegeben ist:

• Die geschätzte Trajektorie als Punktwolke mit n Punkten P0, …, Pn-1 ϵ ℝ3 zum Zeitpunkt i in kartesischen Koordinaten. Damit ist Pi= (xi,yi,zi) ϵ ℝ3.

• Der Zeitstempel T ϵ ℝ für jeden Punkt Pi der Punktwolke.

• Der wahre Mittelpunkt des Targets CG ϵ ℝ3.

• Der Radius rG ϵ ℝ der wahren Trajektorie, welcher gleichzeitig dem Abstand von Kamerazentrum zum Mittelpunkt CG entspricht.

• Die Ebene G in der die Referenztrajektorie verläuft, welche durch drei Punkte (X1, X2, X3 ϵ ℝ3) definiert wird.

Des Weiteren, ist Position und Lage der geschätzten Trajektorie ebenfalls in Quaternionen verfügbar. Für die Berechnungen in dieser Metrik wurden jedoch keine Quaternionen verwendet.

Da der Sensor fix an seiner Position bleibt, daher seine Lage nicht verändert, wurden keine Lagedaten ausgewertet. Diese würden jedoch für weitere Untersuchungen mit


Seite 16

den Koordinaten in Quaternionen zur Verfügung stehen. Wie relevant die Analyse der Lage in diesem Fall sein könnte, wird in Kapitel 7 diskutiert.

4.3.1 Berechnung eines angepassten Kreises für eine 3D-Punktwolke

Ein wesentlicher Anteil der Metrik ist die Berechnung des am besten angepassten Kreises (engl.: Best-Fit Circle, im Folgenden auch Bestfit-Kreis genannt) für eine Punktwolke, in diesem Fall die geschätzte Trajektorie, um als Ersatz für eine Referenztrajektorie zu fungieren. Für dieses bereits bekannte Problem bieten sich verschiedene Lösungsansätze an. Der für diese Metrik erwählte Lösungsansatz umfasst im Wesentlichen drei Schritte und ist angelehnt an [17, 19, 20]:

1. Reduzierung des dreidimensionalen Problems auf ein zweidimensionales durch Projektion der Punktwolke auf die am besten angepasste Ebene (engl.: Best-Fit Plane, im Folgenden auch als Bestfit-Ebene bezeichnet).

2. Anwendung der Methode der kleinsten Quadrate (engl.: Least Squares Fit Method, LSF) [17, 20], um einen angepassten 2D-Kreis für den zweidimensionalen Datensatz der geschätzten Trajektorie zu berechnen.

3. Rücktransformation des 2D-Kreises in 3D-Koordinaten. Alternativ, kann nur das Zentrum des 2D-Kreises zurücktransformiert werden. Der 3D-Kreis wäre dann durch Zentrum, Radius und Normalvektor der Bestfit-Ebene vollständig definiert.

Des Weiteren kann ein Kreis im 3D Raum repräsentiert werden durch folgende parametrische Gleichung:

𝑲(𝑡) = 𝑪𝐾 + 𝒓𝐾 cos(𝑡) 𝒖𝐾 + 𝒓𝐾 sin(𝑡) (𝒏𝐾 × 𝒖𝐾), 0 ≤ 𝑡 ≤ 2𝜋 ( 4–2 )

Dabei ist Vektor nK der Einheitsnormalvektor und uK ein Einheitsvektor, welcher orthogonal zu nK ist. Spezifiziert man die Orientierung mit Hilfe des Zenitwinkels Φ und des Azimuthwinkels Θ erhält man:

𝒏𝐾 = (

cos(𝜙) sin (𝜃)

sin(𝜙) sin(𝜃)

cos(𝜃)) , 𝒖𝐾 = (

− sin(𝜙)

cos(𝜙)0

) ( 4–3 )

Die Ermittlung von nK, sowie die Ermittlung des Radius rK und des Kreismittelpunkts CK wird nun Schritt für Schritt erläutert.

4.3.1.1 Ermittlung der Bestfit-Ebene zu einer 3D-Punktwolke mit Hilfe von SVZ

Erster Schritt ist die Bestimmung des Normalvektors nK der Bestfit-Ebene B. Diese Ebene B ist die Ebene die bestmöglich, bezüglich Nähe, zu den Punkten Pi der 3D Punktwolke passt. Die Nähe wird gemessen mit der Quadratsumme der orthogonalen Distanzen zwischen der Ebene und den Punkten. Dafür wird zunächst eine Matrix A = (P0 – c, …, Pn-1 – c) ϵ ℝn×3 vorgestellt wobei c den Durchschnittswert aller Punkte darstellt:

𝒄 =1

𝑛∑ 𝑷𝑖

𝑛𝑖=0 , 𝒄 ∈ ℝ1×3 ( 4–4 )

Nun kann der Normaleinheitsvektor nK wie folgt ermittelt werden:


Seite 17

𝒏𝐾 = argmin𝒏𝐾 ∈ ℝ3,||𝒏𝐾||=1

||𝑨𝒏𝐾||2

( 4–5 )

Als nächsten wird eine Singulärwertzerlegung mit Matrix A durchgeführt, mit den unitären (orthonormale Spalten und Reihen) Matrizen U, V, sodass man A=UΣVT erhält. Dabei ist Σ eine Diagonalmatrix welche aus den drei Singulärwerten σ1 ≥ σ2 ≥ σ3 ≥ 0 besteht. Diese entsprechen der Quadratwurzel der Eigenwerten λi von ATA [17]. Des Weiteren ist V ϵ ℝ3×3 eine orthogonale Matrix, gefüllt mit den Eigenvektoren von ATA. U ϵ ℝn×n wird für diese Anwendung nicht weiter gebraucht. Eine ausführliche Berechnung der Singulärwertzerlegung ist unter [17] zu finden. Wir erhalten also:

||𝑨𝒏𝐾||2

= ||𝑼𝚺𝑽𝑇𝒏𝐾||2

( 4–6 )

Da sich U aus σi, A und den Eigenvektoren von ATA errechnet und wir lediglich nach dem minimalen Wert für nK suchen, kann man U zur Vereinfachung aus der Gleichung entfernen und lediglich Σ und V betrachten:

||𝚺𝑽𝑇𝒏𝐾||2

= (𝜎1𝑏1)2 + (𝜎2𝑏2)2 + (𝜎3𝑏3)2 𝑚𝑖𝑡 𝒃 = 𝑽𝑇𝒏𝐾 𝜖 ℝ3 ( 4–7 )

Offensichtlich wird nun der Ausdruck auf ein Minimum gebracht, wenn für b=(0,0,1)T gewählt wird, da σ3 den kleinsten der Singulärwert darstellt. Nun erhält man nK durch lösen der Gleichung wie folgt:

𝑽𝑇𝒏𝐾 = 𝒃

𝑽𝑽𝑇𝒏𝐾 = 𝑽𝒃 𝑚𝑖𝑡 𝑽𝑽𝑇 = 𝑰, 𝑑𝑎 𝑽 𝑢𝑛𝑖𝑡ä𝑟 𝑖𝑠𝑡

𝒏𝐾 = 𝑽𝒃 = 𝑽 (001

) ( 4–8 )

Es ergibt sich also, dass der Ausdruck ||AnK||2 minimal ist, wenn der Normalvektor nK der dritten Spalte der Matrix V entspricht.

Ebene B ist nun durch Normalvektor nK und dem Durchschnittswert c, der sich auf der Ebene befindet, vollständig definiert. Nun gilt es die Punkte Pi auf die Ebene B zu projizieren. Hierfür wird das Skalarprodukt jedes Punktes Ai mit dem Normalvektor gebraucht:

𝑷𝑖,𝑝𝑟𝑜𝑗𝑖𝑧𝑖𝑒𝑟𝑡 = 𝑷𝑖 − ⟨𝑨𝑖 , 𝒏𝐾𝑇 ⟩𝒏𝐾

𝑇 ( 4–9 )

Da für den Circlefit-Algorithmus jedoch ein 2D-Datensatz gebraucht wird, muss nun der auf die Ebene projizierte Datensatz Pi,projiziert in das KS der Ebene überführt werden. Dafür gilt es nun die Achsen des neuen KS zu bestimmen und zu Letzt eine Transformation Matrix T damit aufzubauen. Der erste Punkt von Pi,projiziert wird hierbei als Ursprung O definiert. Die z-Achse des neuen KS kann mit dem Kreuzprodukt zweier Vektoren vom Ursprung zu einem beliebigen Punkt von Pi,projiziert und anschließendes Normieren erhalten werde:

𝒛 =𝑶𝑷𝑖,𝑝𝑟𝑜𝑗𝑖𝑧𝑖𝑒𝑟𝑡×𝑶𝑷𝑗,𝑝𝑟𝑜𝑗𝑖𝑧𝑖𝑒𝑟𝑡

||𝑶𝑷𝑖,𝑝𝑟𝑜𝑗𝑖𝑧𝑖𝑒𝑟𝑡×𝑶𝑷𝑗,𝑝𝑟𝑜𝑗𝑖𝑧𝑖𝑒𝑟𝑡|| 𝑚𝑖𝑡 𝑗 > 𝑖, 𝒛 ∈ ℝ3×1 ( 4–10 )

Ähnlich sei die x-Achse definiert durch einen beliebigen Vektor vom Ursprung zu einem Punkt Pi,projiziert:


Seite 18

𝒙 =𝑶𝑷𝑓,𝑝𝑟𝑜𝑗𝑖𝑧𝑖𝑒𝑟𝑡

||𝑶𝑷𝑓,𝑝𝑟𝑜𝑗𝑖𝑧𝑖𝑒𝑟𝑡|| 𝑚𝑖𝑡 𝑓 > 0, 𝒙 ∈ ℝ3×1 ( 4–11 )

Zu Letzt ergibt sich die y-Achse aus dem Kreuzprodukt der x und z-Achse:

𝒚 =𝒛×𝒙

||𝒛×𝒙||, 𝒙 ∈ ℝ3×1 ( 4–12 )

Die Transformationsmatrix T lautet nun:

𝑻 = [𝒙 𝒚 𝒛0 0 0

𝑶1

] ∈ ℝ4×4 ( 4–13 )

Als nächstes wird Pprojiziert um einen Einheitsvektor erweitert:

𝑷𝑝𝑟𝑜𝑗𝑖𝑧𝑖𝑒𝑟𝑡,1 = [𝑷𝑝𝑟𝑜𝑗𝑖𝑧𝑖𝑒𝑟𝑡 1] ∈ ℝn×4 ( 4–14 )

Nun erhält man als Lösung des Gleichungssystems,

𝑻𝑷𝑋𝑌01 = 𝑷𝑝𝑟𝑜𝑗𝑖𝑧𝑖𝑒𝑟𝑡,1𝑇 𝑚𝑖𝑡 𝑷𝑋𝑌01 ∈ ℝ4×n, ( 4–15 )

die auf die Ebene projizierten Koordinaten im Ebenen KS PXY01. Dabei enthalten die Punkte PXY01 momentan noch vier Zeilen. Die dritte Zeile ist gefüllt mit Nullen und die vierte Zeile ist gefüllt mit Einsen, welche von der Transformation übrig bleiben. Somit sind die transformierten Koordinaten:

𝑷𝑋𝑌 = (𝑷𝑋𝑌01(1: 2, : ))𝑇

∈ ℝn×2 ( 4–16 )

Zu beachten ist jedoch, dass dieses Vorgehen nur möglich ist, da es keine Rolle spielt welche Orientierung das Ebenen-KS zum Ursprünglichen KS besitzt. Indem man die Ergebnisse des Circlefits einfach mit der gleichen Transformationsmatrix T zurücktransformiert geht keine Information verloren. Sollte die Orientierung des Ebenen-KS von Interesse sein, bietet sich als Alternative die allgemein bekannte Rodrigues Rotation [21] an. Ohne genauer auf die Funktion einzugehen, projiziert sie und transformiert sie zugleich die Punktewolke in das Ebenen-KS.

4.3.1.2 Ermittlung eines Bestfit-Kreises in 2D mit LSF-Methode

Da man über die 2D Punkte Pi,XY(xi,yi) 0 ≤ i < n verfügt, lässt sich ein beliebiges Verfahren zur Ermittlung eines angepassten Kreises mit den Punkten Ki,XY ϵ ℝn×2 finden. Da sich die meisten Verfahren von der Methode der kleinsten Quadrate (LSF) ableiten, wird diese nun Schritt für Schritt durchgeführt. Dabei wird R. Bullocks Least-Squares circle [20] Fit betrachtet:

Ein Kreis kann im zweidimensionalen Raum mit seinem Radius rK und dem Zentrum cK,XY(xc,yc) vollständig definiert werden. Zuerst wird der Durchschnittswert für xi und yi ermittelt:

�̅� =1

𝑛∑ 𝑥𝑖

𝑛−1𝑖=0 𝑢𝑛𝑑 �̅� =

1

𝑛∑ 𝑦𝑖

𝑛−1𝑖=0 ( 4–17 )

Zur Vereinfachung werden die Koordinaten (u,v) und a eingeführt, sodass

𝑢𝑖 = 𝑥𝑖 − �̅�, 𝑣𝑖 = 𝑦𝑖 − �̅� 𝑢𝑛𝑑 𝑎 = 𝑟𝐾2 ( 4–18 )

entspricht. Ein Kreis kann nun mit der Funktion g(u,v) mit dem Zentrum (uc,vc) beschrieben werden:

𝑔(𝑢, 𝑣) = (𝑢 − 𝑢𝑐)2 + (𝑣 − 𝑣𝑐)2 − 𝑎 ( 4–19 )


Seite 19

Als nächstes muss, entsprechend der LSF-Methode, die Summe der Quadrate S von der Funktion g(u,v) minimiert werden.

𝑆 = ∑ (𝑔(𝑢𝑖, 𝑣𝑖))2𝑛−1

𝑖=0 ( 4–20 )

Um dies zu erreichen wird S nach (a,uc,vc) differenziert und anschließend mit Null gleich gesetzt. So kann ( 4–21 ), ( 4–22 ) und ( 4–23 ) wie folgt erhalten werden:

Für δS/δa=0:

𝜕𝑆

𝜕𝑎= 2 ∑ 𝑔(𝑢𝑖, 𝑣𝑖)

𝜕𝑔

𝜕𝑎(𝑢𝑖, 𝑣𝑖)

𝑛−1𝑖=0 = −2 ∑ 𝑔(𝑢𝑖, 𝑣𝑖)𝑛−1

𝑖=0 = 0

Daher ist der Ausdruck nur 0 wenn:

∑ 𝑔(𝑢𝑖, 𝑣𝑖) = 0𝑛−1𝑖=0 ( 4–21 )

Für δS/δuc=0:

𝜕𝑆

𝜕𝑢𝑐= 2 ∑ 𝑔(𝑢𝑖 , 𝑣𝑖)

𝜕𝑔

𝜕𝑢𝑐(𝑢𝑖, 𝑣𝑖)

𝑛−1𝑖=0 = −4 ∑ (𝑢𝑖 − 𝑢𝑐)𝑔(𝑢𝑖, 𝑣𝑖)𝑛−1

𝑖=0

= −4 ∑ 𝑢𝑖𝑔(𝑢𝑖, 𝑣𝑖)𝑛−1𝑖=0 + 4𝑢𝑐 ∑ 𝑔(𝑢𝑖, 𝑣𝑖)𝑛−1

𝑖=0 = 0 𝑚𝑖𝑡 ∑ 𝑔(𝑢𝑖 , 𝑣𝑖)𝑛−1𝑖=0 = 0

Daher ist der Ausdruck nur 0 wenn:

∑ 𝑢𝑖𝑔(𝑢𝑖, 𝑣𝑖)𝑛−1𝑖=0 = 0 ( 4–22 )

Und schließlich wird bei gleicher Vorgehensweise wie bei ( 4–22 ) für δS/δuc=0 folgendes erhalten:

∑ 𝑣𝑖𝑔(𝑢𝑖, 𝑣𝑖)𝑛−1𝑖=0 = 0 ( 4–23 )

Nun muss ( 4–22 ) ausmultipliziert werden um ( 4–24 ) zu erhalten:

∑ 𝑢𝑖[𝑢𝑖2 − 2𝑢𝑖𝑢𝑐 + 𝑢𝑐

2 + 𝑣𝑖2 − 2𝑣𝑖𝑣𝑐 + 𝑣𝑐

2 − 𝑎]𝑛−1𝑖=0 = 0 ( 4–24 )

Daher ist Σiui=0 und es wird zur Vereinfachung der Gleichung Su=Σiui, Suu= Σi(ui)2, Suuu= Σi(ui)3, Sv= Σivi, Svv= Σi(vi)2, Svvv= Σi(vi)3, Suv=Σi(uivi), Suuv=Σi(uiuivi), Suvv= Σi(uivi vi) definiert. Somit ergibt sich die Gleichung ( 4–24 ) zu:

𝑆𝑢𝑢𝑢 − 2𝑢𝑐𝑆𝑢𝑢 + 𝑢𝑐2𝑆𝑢 + 𝑆𝑢𝑣𝑣 − 2𝑣𝑐𝑆𝑢𝑣 + 𝑣𝑐

2𝑆𝑢 − 𝑎𝑆𝑢 = 0

𝑢𝑐𝑆𝑢𝑢 + 𝑣𝑐𝑆𝑢𝑣 =1

2(𝑆𝑢𝑢𝑢 + 𝑆𝑢𝑣𝑣) 𝑑𝑎 𝑆𝑢 = 0 ( 4–25 )

Mit ähnlicher Vorgehensweise und Sv=0 kann ( 4–26 ) erhalten werden:

𝑢𝑐𝑆𝑢𝑣 + 𝑣𝑐𝑆𝑣𝑣 =1

2(𝑆𝑣𝑣𝑣 + 𝑆𝑣𝑢𝑢) ( 4–26 )

Die Koordinaten (uc,vc) können erhalten werden wenn die beiden Gleichungen ( 4–25 ) und ( 4–26 ) ineinander eingesetzt werden oder das entstehende Gleichungssystem gelöst wird. Das Zentrum in den Ursprünglichen Koordinaten CK,XY(xc,yc) kann erhalten werden, wenn ( 4–18 ) umgestellt wird und die jeweiligen Mittelwerte wieder auf (uc,vc) addiert werden.

Für den Radius muss ( 4–21 ) ausmultipliziert werden um wieder ( 4–24 ) zu erhalten. Anschließend wird Sv=Su=0 eingesetzt und nach umformen ergibt sich rK zu:

𝑟𝐾 = √𝑎 = √𝑢𝑐2 + 𝑣𝑐

2 +𝑆𝑢𝑢+𝑆𝑣𝑣

𝑛 ( 4–27 )


Seite 20

Wird CK,XY und rK in die Kreisgleichung ( 4–2 ) für den zweidimensionalen Fall (ohne Normalen und Richtungsvektor) eingesetzt, kann schließlich der Kreis KXY mit den Punkten Ki,XY erhalten werden. KXY und PXY sind in dargestellt.

Abb. 4–3: Bestfit-Kreis für die Punktwolke in 2D

4.3.1.3 Rücktransformation in 3D-Raum

Den zweidimensionalen Kreis KXY gilt es nun wieder in den dreidimensionalen Raum zurück zu transformieren. Dafür wird KXY wieder um eine Spalte mit Nullen und eine Zeile mit Einsen erweitert, sodass die Matrix KXY01 bereit für die Transformation ist.

𝑲𝑋𝑌01 = [𝑲𝑋𝑌 0 1] ∈ ℝn×4 ( 4–28 )

Für die Rücktransformation in den dreidimensionalen Raum wird ein Gleichungssystem mit der inversen Transformationsmatrix T erstellt:

𝑻−1𝑲𝑋𝑌𝑍1 = 𝑲𝑋𝑌01𝑇 𝑚𝑖𝑡 𝑲𝑋𝑌𝑍1 ∈ ℝ4×n ( 4–29 )

Zu Letzt wird der rücktransformierte Kreis K im 3D-Raum erhalten:

𝑲 = 𝑲𝑋𝑌𝑍 = (𝑲𝑋𝑌𝑍1(1: 3, : ))𝑇

∈ ℝn×3 ( 4–30 )

Alternativ kann K über die Kreisgleichung ( 4–2 ) berechnet werden. Dafür muss nur der Kreismittelpunkt CK,XY im 2D analog wie in ( 4–29 ) in 3D überführt werden um somit CK zu erhalten. Einheitsnormalvektor, Richtungsvektor und Radius sind ebenfalls bereits bekannt und können in ( 4–2 ) eingesetzt werden. Da für das weitere Vorgehen der Kreismittelpunkt CK sowieso gebraucht wird, bietet sich dieses Verfahren besonders an. Zu Letzt ist K und die Punktwolke in zu sehen.


Seite 21

Abb. 4–4: Bestfit-Circle K in Orange und Punktwolke der geschätzten Trajektorie in Blau.

4.3.2 Berechnung der Elevation zur Referenzebene

Eine der ersten Werte, welche während der beschriebenen Circlefit-Methode erhalten werden können ist der Einheitsnormalvektor nK der Bestfit-Ebene. Dieser wird benötigt um ε zu berechnen.

Um den Winkel zwischen zwei sich schneidenden Ebenen zu bestimmen, müssen ihre beiden Normalvektoren betrachtet werden. Die Ebene, in der sich das Target relativ zur Kamera dreht, kann über die drei Punkte X1, X2 und X3 bestimmt werden. Dafür wird der gleiche Vorgang wie in 4.3.1.1 verwendet. Mit dem erhaltenen Einheitsnormalvektor nG ϵ ℝ3 ist es nun möglich den Winkel ε zwischen den Ebenen mit folgender allgemein bekannten Formel [22] zu bestimmen:

휀 = arccos (|⟨𝒏𝐾,𝒏𝐺⟩

||𝒏𝐾||||𝒏𝐺|||) ( 4–31 )

Dieser Winkel ε kann als Elevation des Bestfit-Kreises zu der Referenzebene bezeichnet werden und wird in Grad angegeben. Ungewollte Strukturen außerhalb des betrachteten Objekts, führen zu einem beträchtlichen Anstieg der Elevation.

4.3.3 Berechnung des durchschnittlichen Residuums

Für den nächsten Parameter wird der Abstand zwischen einem Punkt Pi und dem nächsten, bezogen auf die euklidische Distanz, Punkt Ki auf dem Bestfit-Kreis K ermittelt. Dieser minimale Abstand di,min ist dementsprechend definiert als:

𝑑𝑖,𝑚𝑖𝑛 = min({𝑑𝑖,0, 𝑑𝑖,1, … 𝑑𝑖,𝑗 … 𝑑𝑖,𝑛−1})

mit

𝑑𝑖,𝑗 = ||𝑷𝑖𝑲𝑗|| 𝑚𝑖𝑡 0 ≤ 𝑗 < 𝑛 ( 4–32 )

Für jeden Punkt Pi existiert ein nächster Punkt Ki und somit wird der Vektor dmin, bestehend aus n minimalen Abständen di,min erstellt:

𝒅𝑚𝑖𝑛 = (𝑑0,𝑚𝑖𝑛, 𝑑1,𝑚𝑖𝑛, … 𝑑𝑖,𝑚𝑖𝑛 … 𝑑𝑛−1,𝑚𝑖𝑛)𝑇

∈ ℝn ( 4–33 )


Seite 22

Nun lässt sich der für die Auswertung relevante Parameter R berechnen. R ist das durchschnittliche Residuum und damit der Durchschnittswert von dmin. Er wie folgt berechnet:

𝑅 =1

𝑛∑ 𝑑𝑖,𝑚𝑖𝑛

𝑛−1𝑖=0 ( 4–34 )

Zur weiteren Analyse, wurden außerdem die Abstände di,min in ihre XY-Komponente di,minXY und Z-Komponente di,minZ unterteilt. Die XY-Komponente entspricht dabei dem Abstand zum nächsten Punkt im zweidimensionalen Ebenen KS aus 4.3.1.2. Die Z-Komponente entspricht dem Abstandswert entlang der Z-Achse des lokalen Ebenen-KS, welches in 4.3.1.1 erstellt wurde. Dabei wird di,minXY genau wie in ( 4–32 ), jedoch mit den entsprechenden 2D Werten berechnet:

𝑑𝑖,𝑚𝑖𝑛𝑋𝑌 = min({𝑑𝑖,0,𝑋𝑌, 𝑑𝑖,1,𝑋𝑌, … 𝑑𝑖,𝑗,𝑋𝑌 … 𝑑𝑖,𝑛−1,𝑋𝑌})

mit

𝑑𝑖,𝑗,𝑋𝑌 = ||𝑷𝑖,𝑝𝑟𝑜𝑗𝑖𝑧𝑖𝑒𝑟𝑡𝑲𝑗,𝑋𝑌|| 𝑚𝑖𝑡 0 ≤ 𝑗 < 𝑛 ( 4–35 )

di,minZ kann einfach durch mit umstellen des Satzes von Pythagoras berechnet werden:

𝑑𝑖,𝑚𝑖𝑛𝑍 = √𝑑𝑖,𝑚𝑖𝑛2 − 𝑑𝑖,𝑚𝑖𝑛𝑋𝑌

2 ( 4–36 )

Somit ergeben sich die beiden Vektoren dminXY und dminZ zu:

𝒅𝑚𝑖𝑛𝑋𝑌 = (𝑑0,𝑚𝑖𝑛𝑋𝑌, 𝑑1,𝑚𝑖𝑛𝑋𝑌, … 𝑑𝑖,𝑚𝑖𝑛𝑋𝑌 … 𝑑𝑛−1,𝑚𝑖𝑛𝑋𝑌)𝑇

∈ ℝn ( 4–37 )

𝒅𝑚𝑖𝑛𝑍 = (𝑑0,𝑚𝑖𝑛𝑍, 𝑑1,𝑚𝑖𝑛𝑍, … 𝑑𝑖,𝑚𝑖𝑛𝑍 … 𝑑𝑛−1,𝑚𝑖𝑛𝑍)𝑇

∈ ℝn ( 4–38 )

Damit drückt R eine Form von geometrischer Ähnlichkeit der geschätzten Trajektorie zu einem Kreis aus. Je größer der Wert R ist, desto weniger ähnelt der Verlauf der geschätzten Trajektorie, dem eines Kreises. Diese Aussage gilt jedoch nur, wenn der Drift dabei gering ist.

An diesem Punkt fällt möglicherweise auf, dass die geometrische Ähnlichkeit und der Drift zusammenhängen. Dies ist darin begründet, dass der Drift den rotatorischen Fehleranteil und die geometrische Ähnlichkeit den translatorischen Fehleranteil zum absoluten euklidischen Positionsfehler eines Punktes Pi zum einem entsprechenden Punkt auf dem Besfit-Kreis Ki beiträgt. Da der translatorische Fehleranteil bereits den Fehler außerhalb der Bestfitebne darstellt, reicht bei der Berechnung des Driftwinkels δ eine rein zweidimensionale Betrachtung innerhalb der Bestfit-Ebene. Es wurde entschieden nicht den absoluten Positionsfehler, sondern die beiden Beiträge isoliert zu betrachten, um eine gezieltere Aussage über den Effekt bestimmter Einflussfaktoren zu treffen.

4.3.4 Berechnung des Drifts

Um den Drift D zu erhalten muss zunächst der Driftwinkel δ berechnet werden. Zur Veranschaulichung dieser eher abstrakten Werte, werden in Abb. 4–5 einige der zur Berechnung nötigen Parameter dargestellt.


Seite 23

Abb. 4–5: Winkel Vektoren und Punkte für die Berechnung von δi

Des Weiteren, wird die Annahme getroffen, dass genauso viele Punkte Ki,XY wie Pi,projiziert existieren. So gibt es für jeden Punkt Pi,projiziert auf der geschätzten Trajektorie einen Punkt Ki,XY auf dem Bestfit-Kreis. Der Drift wird im zweidimensionalen, ausgehend von den projizierten Trajektorien Koordinaten Pi,projiziert berechnet. Erster Schritt zur Berechnung der Driftwinkel δi ist die Erstellung der Vektoren pi, ki und s. Diese müssen außerdem in normierter Form vorliegen:

𝒑𝑖 =(𝑪𝐾,𝑋𝑌𝑷𝑖,𝑝𝑟𝑜𝑗𝑖𝑧𝑖𝑒𝑟𝑡)

||𝑪𝐾,𝑋𝑌𝑷𝑖,𝑝𝑟𝑜𝑗𝑖𝑧𝑖𝑒𝑟𝑡||, 𝒌𝑖 =

(𝑪𝐾,𝑋𝑌𝑲𝑖,𝑋𝑌)

||𝑪𝐾,𝑋𝑌𝑲𝑖,𝑋𝑌|| 𝑚𝑖𝑡 𝒑𝑖, 𝒌𝑖 , 𝒔 ∈ ℝ2

und

𝒔 =(𝑪𝐾,𝑋𝑌𝑷0,𝑝𝑟𝑜𝑗𝑖𝑧𝑖𝑒𝑟𝑡)

||𝑪𝐾,𝑋𝑌𝑷0,𝑝𝑟𝑜𝑗𝑖𝑧𝑖𝑒𝑟𝑡|| 𝑚𝑖𝑡 𝒔 ∈ ℝ2 ( 4–39 )

Da Winkel >180 °, und im Falle von einem Voreilen der geschätzten Trajektorie <0 °, eintreffen können, ist es nicht möglich den Winkel zwischen zwei Vektoren mit einer arccos-Funktion zu errechnen. Um also solche Driftwinkel darzustellen, wird die arctan2-Funktion verwendet, da sie die Fähigkeit besitzt Winkel von -180 ° bis 180 ° darzustellen. Sie teilt das KS wie auf Abb. 4–6 dargestellt auf.

Abb. 4–6: KS Aufteilung durch arctan2; Darstellung links aus [23] und rechts abgeändert aus [24]


Seite 24

Damit werden zunächst die beiden Hilfswinkel berechnet:

𝛼𝑖 = 𝑎𝑟𝑐𝑡𝑎𝑛2((det (𝑨𝑖), ⟨𝒔𝑖, 𝒑𝑖⟩)

mit

𝑨𝑖 = [𝒔𝑖𝑇 𝒑𝑖

𝑇] ∈ ℝ2x2 ( 4–40 )

Auf identische Weise mit ki an Stelle von pi wird βi errechnet und schließlich ergibt:

𝛿𝑖 = 𝛽𝑖 − 𝛼𝑖 ( 4–41 )

Nun ergibt sich D zu:

𝑫 = (𝛿0, 𝛿1 … 𝛿𝑖 … 𝛿𝑛−1)𝑇 ∈ ℝn ( 4–42 )

Für die Bewertung der Einflussfaktoren kann nun der Verlauf von D, mit δi auf der Ordinate und i auf der Abszisse, betrachtet werden, oder der absolute Maximalwert den δi annimmt. Dieser Wert wird als δi,max bezeichnet:

𝛿𝑖,𝑚𝑎𝑥 = max(|𝑫|) ( 4–43 )

Der Absolutwert wird betrachtet, weil ein „Voreilen“ (negatives δi), die gleiche Bedeutung für die Rekonstruktionsgüte wie ein „Hinterherhinken“ (positives δi), besitzt. Ein δi von -45 °, ist damit genauso schädlich wie ein δi von 45 °. Des Weiteren ist der Maximalwert entscheidend und nicht der Endwert δn-1, da der „Schaden“( siehe Abb. 4–1 rechts), der an einem bestimmten Punkt i der Trajektorie verrichtet wurde, nicht ausgebessert werden kann.

Bei der Implementierung dieser Methode in MATLAB können Ausreißer und Richtungswechsel für Probleme sorgen, dies kann jedoch mit Hilfe bestimmter Bedingungen, auf die in 4.4.5 eingegangen wird, behoben werden.

4.3.5 Abweichung von Radius und Zentrum

Die letzten Parameter die noch nicht auf ihren Fehler untersucht wurden sind der Radius rK und das Zentrum CK des Bestfit-Kreises K.

Da der wahre Radius rG und das wahre Zentrum CG bekannt sind. Wird an dieser Stelle einfach die Differenz gebildet bzw. der euklidische Abstand angegeben. So ergibt sich der Fehler für den Radius zu rF und der Abstand zum wahren Zentrum zu CF wie folgt:

𝑟𝐹 = 𝑟𝐺 − 𝑟𝐾 𝑢𝑛𝑑 𝐶𝐹 = ||𝑪𝐺𝑪𝐾|| ( 4–44 )

Bei großer Abweichung können diese beiden Parameter einen erheblichen Einfluss auf die Rekonstruktionsgüte haben.

4.4 Implementierung in MATLAB

Die Implementierung erfolgte in MATLAB 2015b, da viele aufwendige Rechenoperationen bereits als Funktionen zur Verfügung stehen und es durch die Matrixbasiert Rechenweise große Datenmengen schnell bewältigen kann. Dieser Abschnitt gibt einen Überblick darüber, welche Funktionen sich für die Berechnung der einzelnen Parameter als nützlich erweisen. Des Weiteren wird auf Probleme


Seite 25

hingewiesen die bei der Implementierung auftreten können und was unternommen wurde um diese zu lösen.

Die Metrik besteht insgesamt aus acht Skripten. Sechs dieser Skripte sind für den in beschriebenen Berechnungsteil verantwortlich. Sie werden nacheinander von der Funktion mainfunctionMetric.m aufgerufen. Diese erhält die benötigen Parameter

über das metricexe.m Skript und daher vom Benutzer selbst. Vorab ist ein Überblick

über diesen Sachverhalt in Abb. 4–7 gegeben.

Abb. 4–7: Programmablaufplan der Metrik

Die im MATLAB-Skript verwendeten Bezeichnungen für die verschiedenen Parameter entsprechen zum Großteil den Bezeichnungen, welche während der mathematischen Herleitung verwendet wurden. Dabei wurde ein Unterstrich vor tiefgestellten Indices verwendet, da eine Tiefstellung von Indices in MATLAB nicht möglich ist. Des Weiteren ist das komplette Dokument in Englisch geschrieben. Daher wurden die Indices der Parameter in das Englische übersetzt. Zu Letzt werden noch ein paar Ausnahmen bei der Benennung der Parameter genannt:

• Pi=P_trajectorymatrix

• circlepart beschreibt wie viel Teile eines kompletten Kreises abgefahren

wurden. Entspricht der Wert 1, so wurde genau ein Kreis abgefahren.

• Die drei Punkte X1, X2, X3 werden als Matrix namens planeparametersX1X2X3 abgerufen.

• Alle griechischen Buchstaben außer ε werden ausgeschrieben. Für ε wurde der Parameter elevation gewählt.


Seite 26

4.4.1 Ausführungs- und Hauptfunktion

Im Ausführungsskript metricexe.m können verschiedene Parameter konfiguriert

werden, wie beispielsweise der Abstand zum Mittelpunkt oder die Lage des Targets. Diese Parameter werden der Hauptfunktion mainfunctionMetric.m weitergegeben.

In der Hauptfunktion erfolgt zu Nächst die Auswahl des zu analysierenden Datensatzes mit Hilfe von uigetfile()Funktion und anschließend das Abrufen der

Funktionen aller Module. Außerdem wird an dieser Stelle erkannt ob es sich bei dem eingelesenen Datensatz um eine Aufnahme der Kinect v2, der ZED oder der PMD Kamera handelt. Dabei muss der erste Buchstabe der eingelesenen Trajektorien-Datei den Anfangsbuchstaben des jeweiligen Sensors besitzen, da dieser für die Kategorisierung des Datensatzes verwendet wird. Wichtig wird dieser Typ des Datensatzes bei der Funktion trajectorydata.m. Sie wird als erstes von der

Hauptfunktion aufgerufen und liest den Zeitstempel sowie sämtliche Positions- und Lagekoordinaten aus dem Datensatz mit textread() aus und erstellt aus den

kartesischen Positionskoordinaten eine Matrix namens trajectorymatrix.

Außerdem kann nun mit dem Typ des Datensatzes, dem Zeitstempel und der bekannten Rotationsgeschwindigkeit errechnet werden wie viel Grad bei der Umdrehung abgefahren wurden. In allen Versuchen der Hauptversuchsreihe lag der Wert zwischen 350 ° und 370 °. Der Typ ist hierbei entscheidend, da die Zeiteinheit des Zeitstempels für jeden Sensor unterschiedlich ist.

Die Positionsmatrix trajectorymatrix wird nun zusammen mit anderen

Konfigurationsparametern an die Funktion bestfitcircleparameter.m

weitergegeben, welche den Circlefit-Algorithmus ausführt.

4.4.2 Implementierung und Auswahl des Circlefit-Algorithmus

Aus Positionsmatrix, Distanz zum Mittelpunkt und Sensortyp werden mit der Funktion bestfitcircleparameter.m sämtliche Parameter des Bestfit-Kreises berechnet.

Wie in 4.3.1 muss nun als erstes der Normaleinheitsvektor der Bestfitebene ermittelt werden. Für die Singulärwertzerlegung existiert bereits die Funktion [U,S,V]=svd()

mit der die Eigenvektormatrix berechnet wird. Zu beachten ist hierbei, dass je nach Betriebssystem und Konfiguration nicht genügend Speicher für die Matrix U vorhanden sein könnte. Im Fall von Datensätzen mit 10000 Bildern, war die Ausführung der Funktion an einem 32bit Vista Computer mit U ϵ ℝ10000×10000 nicht möglich. Deshalb wurde eine alternative in die Metrik eingebaut, in dem mit der Funktion eig() die Eigenvektoren der Matrix ATA errechnet wurden. Da nur ein

Eigenwert ermittelt wird, stellt dieser den Normalvektor nK der Ebene dar. Sonst ist der kleinste Eigenwert zu wählen. Nun wird mit dem in 4.3.1.1 beschriebenen Verfahren die Trajektorie auf die Bestfit-Ebene projiziert und im transformierten KS dargestellt. Für die Berechnung des Bestfit-Kreises kann nun zwischen zwei implementierten Circlefit-Algorithmen gewählt werden. Es kann zwischen dem LeastSquareFit() Algorithmus, welcher in 4.3.1.2 ausführlich beschrieben wurde

und dem CircleFitByTaubin() [25], welcher auf der LSF Methode basiert und ein

besonders stabiles [26] Ergebnis verspricht gewählt werden. Beide Ergebnisse liefern näherungsweise das gleiche Ergebnis mit einer Abweichung von unter 0.1% für Zentrum und Radius. Der LeastSquareFit() Algorithmus arbeitete jedoch bei

sämtlichen Auswertungen schneller.


Seite 27

Nachdem der Besfit-Kreis zurück in den 3D Raum transformiert wurde, gilt es nun den Abstand CF zu berechnen. Der Referenzmittelpunkt CG,OT ist jedoch nur im OptiTrack-KS vorhanden. Daher muss CG,OT in das Kamera-KS transformiert werden um ihn mit CK zu vergleichen. Im verwendeten Szenario ist das OptiTrack-KS um 90 ° um die Y-Achse im Uhrzeigersinn bezogen auf das Kamera-KS verdreht und um einen bestimmten vom verwendeten Sensor abhängigen Vektor verschoben. Der Vektor vom Kameramittelpunkt CS,OT ϵ ℝ3 zum Referenzmittelpunkt CG,OT muss also mit der Transformationsmatrix RY multipliziert werden um den Referenzmittelpunkt CG im Kamera-KS zu erhalten:

𝑪𝐺 = 𝑹𝑌𝑪𝑆,𝑂𝑇𝑪𝐺,𝑂𝑇 = [0 0 10 1 0

−1 0 0] 𝑪𝑆,𝑂𝑇𝑪𝐺,𝑂𝑇 ( 4–45 )

Hierbei erfüllt der Typ der des Sensors eine wichtige Rolle, da für jeden Sensor ein anderer Kameramittelpunkt existiert. Für den PMD-Sensor ist diese Information nicht vorhanden. Daher ist für ihn keine Berechnung von CF möglich.

4.4.3 Ermittlung der Referenzebene im Kamera-KS

Die Referenzebene wird mit Hilfe von den drei Eckpunkten X1, X2, X3 ϵ ℝ3 des Targets berechnet. Diese wurden mit Hilfe des OptiTrack-Systems erfasst. Um die Referenzebene im Kamera-KS zu erhalten müssen die drei Punkte mit RY wie in ( 4–45 ) transformiert werden. Anschließend ist die Referenzebene mit drei Punkten vollständig definiert. Anzumerken ist jedoch, dass es nur möglich ist die Ebene zu erhalten in der sich das Target dreht, da es sich hierbei um einen starren Körper handelt.

4.4.4 Bestimmung des nächsten Punktes auf dem Bestfit-Kreis

Den Abstand eines Punktes Punkt Pi auf der geschätzten Trajektorie zum nächsten Punkt Kj gemäß ( 4–35 ) zu finden ist in MATLAB ein einfaches Unterfangen. Die Funktion knnsearch(A,B) findet die kleinsten euklidischen Distanzen zwischen

Punkten der Matrix B ϵ ℝn×3 und Punkten der Matrix A ϵ ℝn×3. Die Ausgabe erfolgt in Form des Vektors dmin mit einem Distanzeintrag für jeden Punkt Pi. Für weitere Informationen zur Funktion siehe [27].

4.4.5 Herausforderungen bei der Bestimmung des Drifts

Zwei Herausforderungen ergeben sich bei der Berechnung des Drifts im beschriebenen Szenario.

1. Beliebige Umdrehungsrichtung des Targets. 2. Überschreiten der Sektionsgrenze der Funktion atan2 an Anfang und Ende

der Umdrehung

Dadurch, dass die Umdrehungsrichtung beliebig gewählt werden kann, muss der Algorithmus in der Lage sein die Umdrehungsrichtung festzustellen. Dafür wird der Winkel αi betrachtet. Wie in 4.3.4 beschrieben unterteilt der arctan2, bzw. die Funktion atan2()in MATLAB, das KS in zwei Sektionen. Dreht sich das Target

gegen den Uhrzeigersinn in mathematisch positive Richtung, so nimmt αi zu Nächst einen positiven Wert an und befindet sich in der positiven Sektion, welche von 0 bis


Seite 28

π reicht. Überschreitet der Winkel jedoch das Ende der ersten Sektion bei +π startet er in der negativen Sektion, welche von -π bis 0 reicht, wieder mit -π. Eine mathematisch negative Umdrehung startet dementsprechend in der negativen Sektion. Zur Veranschaulichung ist in Abb. 4–8 eine mathematisch positive Umdrehung auf der linken Seite und eine mathematisch negative Umdrehung auf der rechten Seite dargestellt.

Abb. 4–8: Verlauf des Winkels αi von Versuch Nr. 9 (Tab. 5–11). Links für den mathematisch positiven Fall und rechts für den mathematisch negativen Fall.

Eine mathematisch positive Drehrichtung wird erkannt, wenn die Summe (anglesum

im MATLAB Skript genannt) einer anpassbaren Anzahl k an Winkeln αi größer als Null ist. Ist die Summe kleiner als Null, so wird die Umdrehungsrichtung als mathematisch negativ eingeschätzt. Dabei ist darauf zu achten, dass k groß genug ist, damit mögliche Ausreißer, welche durch Richtungswechsel entstehen, keinen Einfluss auf das Urteil erhalten und klein genug, um nicht die Winkel nach dem Sprung mit zu berücksichtigen. Da sämtliche Versuche mindestens 2400 Aufnahmen besaßen, wurde k auf 1000 gesetzt. Ist die Richtung erkannt, wird bei negativer Umdrehungsrichtung αi mit -1 multipliziert. Um den Sprung beim Sektionswechsel zu beseitigen werden dann für Werte kleiner als Null 360 ° addiert. Somit erhält man die Darstellung in Abb. 4–9.

Abb. 4–9: αi für Versuch Nr. 9 nachdem für Werte kleiner als Null 360 ° addiert wurden

Die zweite Herausforderung sind die Richtungswechsel zu Beginn der Aufnahme. Hat sich der Algorithmus für eine Umdrehungsrichtung entschieden kommt es


Seite 29

dennoch vor, dass die Trajektorie unter Umständen in die entgegengesetzte Richtung läuft. Wenn dies gleich zu Beginn passiert kann es vorkommen, dass vereinzelt Punkte der geschätzten Trajektorie von einer in die andere Sektion springen und damit ihr Wert negativ anstatt positiv, bzw. positiv anstatt negativ, ist. Wurde also die Umdrehungsrichtung mathematisch positiv eingeschätzt und ein Punkt befindet sich anfangs in der negativen Sektion, so wird nach dem zuvor beschriebenen Kriterium ein Wert von 360 ° addiert und es kommt zu Ausreißern im Driftwinkel δi wie in Abb. 4–10 (links) abgebildet.

Abb. 4–10: Links δi mit Ausreißern. Rechts δi ohne Ausreißer für Versuch Nr. 8.

Außerdem kann es zu Ausreißern am Ende der Trajektorie kommen, wenn sie ein weiteres Mal die Grenze überschreitet. Dies geschieht für den Fall, dass ein Winkel αi>360 ° für einen Punkt Pi geschätzt wird. Für die Ausreißer am Anfang muss verhindert werden, dass 360 ° von αi abgezogen werden und für die Ausreißer am Ende der Trajektorie müssen 360 ° zu αi addiert werden, um das Problem zu beheben.

Abschließend wurde eine Möglichkeit implementiert die Zunahme des Driftwinkels pro 100 Bilder grafisch darzustellen. Diese Funktion wurde jedoch nur für die Analyse der Ergebnisse verwendet und wird in 6.2 erklärt.

Nachdem die mathematischen Prinzipien die der Metrik zu Grunde liegen behandelt wurden und auf Besonderheiten bei der Implementierung in MATLAB hingewiesen wurde, gilt es nun die Metrik mit dem RACOON-Lab und der EPOS-Anlage zu validieren.

Validierung der Metrik

Seite 30

5 Validierung der Metrik

Die Validierung der Metrik erfolgt anhand der beiden Versuchsanlagen RACOON-Lab und EPOS. Im folgenden Kapitel wird eine Übersicht über die beiden genannten Anlagen gegeben. Im Fokus stehen hierbei die verschiedenen Kameras, Satelliten-Mockups und Sonnensimulatoren. Des Weiteren werden die Anlagen, unter anderem, in Bezug auf ihre Komplexität, Genauigkeit und Erzeugbarkeit realistischer Lichtverhältnisse, verglichen. So können beide Forschungseinrichtungen für zukünftige Projekte, von den gegenseitigen Vorteilen beider Anlagen profitieren. Die Informationen über die EPOS Anlage wurden im Rahmen eines zweimonatigen Austauschprojektes gesammelt.

5.1 RACOON-Lab

5.1.1 Überblick

Das RACOON-Lab ist ein umfangreich ausgestatteter HIL-Simulator für Rendezvous-Szenarien im Erdorbit, welcher sich im Besitz des LRT befindet [2]. Die Abb. 5–1 zeigt eine Konzeptzeichnung des kompletten Systems. Das RACOON-Lab erlaubt die orbitmechanisch korrekte Abbildung verschiedener Konstellationen zwischen Zielsatellit (Target) und teleoperiertem Vefolgersatellit (Servicer).

Abb. 5–1: Konzeptzeichnung des RACOON-Lab, entnommen aus [28]

Der Servicer ist dabei mit den zwei Sensorsystemen, ZED und Kinect v2, ausgestattet. Die von den Sensorsystemen generierten Daten, werden auf einem auf dem Servicer montierten Computer (im Folgenden als Sensorcomputer bezeichnet), weiterverarbeitet und dem Operator optisch aufbereitet zur Verfügung gestellt.

Die Steuerung der Anlage erfolgt über ein in LabVIEW erstelltes virtuelles Interface (engl.: Virtual Interface, VI). Über das VI können die insgesamt dreizehn


Seite 31

Freiheitsgrade der Anlage angesteuert und kontrolliert werden. Dabei kann Geschwindigkeit, Beschleunigung und Position angegeben werden.

Außerdem wurde im Zuge einer Masterarbeit [29] ein Motion Capture System namens OptiTrack in die Anlage integriert. Es soll dabei helfen, die Positionen der einzelnen Module der Anlage, mit Hilfe von acht Kameras, relativ zum OptiTrack KS zu bestimmen. Die Genauigkeit des Systems liegt bei bewegten Objekten im Millimeter-Bereich [29]. In zukünftigen Projekten, soll es möglich sein mit dem OptiTrack System den Groundtruth der Satelliten in Echtzeit bestimmen zu können. Dies führe zu einer Erweiterung des Analysetools. Zum Zeitpunkt, dieser Arbeit ist dies noch nicht möglich. Die Ansteuerung des OptiTrack-Systems kann über einen externen Computer erfolgen.

Eine ausführliche Beschreibung der gesamten Start- und Bedienprozedur (engl.: Start-up-procedure) lässt sich unter [30] finden.

5.1.1.1 Benutzeroberfläche

Auf dem Sensorcomputer kann von einem externen Computer das Softwareframework [4] gestartet werden. Das Softwareframework wurde von T. Wiese in seiner Semesterarbeit konzipiert und implementiert. Im Folgenden wird die Benutzeroberfläche zusammengefasst erläutert. Für Details zur Implementierung sei auf [4] verwiesen. Über die Benutzeroberfläche (siehe Abb. 5–2) des Softwareframeworks, stehen dem Operator mehrere Funktionen zur Verfügung:

Abb. 5–2: Hauptfenster der Benutzeroberfläche des SF. Aufnahme von Kinect v2.


Seite 32

Die Benutzeroberfläche ist aufgeteilt in zwei Fenster. Das Hauptfenster dient zur Modulsteuerung und das Visualisierungsfenster zur Darstellung der Ausgabedaten [4].

Mithilfe des Hauptfensters ist es möglich den Driver, Tracker und Mapper anzusteuern, einzustellen und oder den Status einzusehen. Für den Driver lässt sich über ein Drop-Down-Menü auswählen, welche Datensätze, eingelesen und verarbeitet werden sollen. So kann zwischen den momentan aufgenommenen Daten der ZED, Kinect v2, oder bereits abgespeicherten Datensätzen gewählt werden. Die Datensätze sollten hierbei aus folgenden Dateien bestehen:

• Unterordner depth mit 16-bit-Grauwert-PNG Dateien als Tiefenbilder.

• Unterordner rgb mit 8-bit-RGB-PNG Dateien als Farbbilder.

• Eine Datei Namens rgb.txt mit einer Zeile pro Bild, jeweils mit dem

Zeitstempel in Sekunden gefolgt vom zugehörigen Dateipfad des Farbbildes. Beispiel:

# color images # line format: timestamp filename 4597.977514 rgb/4597.977514.png 4598.044457 rgb/4598.044457.png 4598.111465 rgb/4598.111465.png [...]

• Eine Datei Namens depth.txt mit einer Zeile pro Bild, jeweils mit dem

Zeitstempel in Sekunden gefolgt vom zugehörigen Dateipfad des Tiefenbildes. Beispiel:

# depth images # line format: timestamp filename 4597.977513 depth/4597.977513.png 4598.044457 depth/4598.044457.png 4598.111465 depth/4598.111465.png [...]

• Eine Datei Namens intrinsics.txt mit den intrinsischen

Kameraparametern in Pixeln. Beispiel:

# rgb and depth image intrinsics # fx fy cx cy 366.2 366.2 259.7 202.2

• Eine Datei Namens scale.txt mit dem Skalierungsfaktor zwischen

Tiefenbild-Pixelwerten und Entfernung in Metern. Die Tiefenwerte der ZED und Kinect v2 werden in Millimetern ausgegeben, daher ein Skalierungsfaktor von 1000. Beispiel:

# depth image scale factor 1000

• Alle mit einem ‚#‘ beginnenden Zeilen sind Kommentarzeilen.


Seite 33

Des Weiteren lässt sich in der Driver-Spalte des Hauptfensters ein Boxfilter konfigurieren.

Der Boxfilter legt einen einfachen dreidimensionalen Kubus, wie in Abb. 5–3 dargestellt, um einen bestimmbaren Bereich und erlaubt somit störende Strukturelemente im Hintergrund auszublenden.

Abb. 5–3: Achsen des Boxfilters, abgeändert entnommen aus [31]

In Abb. 5–4 ist die Auswirkung des Boxfilters auf Farb- und Tiefenbild zu erkennen. Dabei wird der Boxfilter sowohl im RGB, als auch im Tiefenbild Datensatz angewendet. Definiert wird die Box entlang der Achsen u, v und z, wobei u und v in Pixeln und z in Metern angegeben wird [4].

Abb. 5–4: Anwendung eines kubischen Filters auf RGB- und Tiefenbilder der Kinect v2 entnommen aus [31]. Links oben ist das RGB-Bild unbearbeitet und rechts oben mit Boxfilter, links unten

das Tiefenbild unbearbeitet und rechts unten mit Boxfilter dargestellt.


Seite 34

In der Tracker-Spalte und Mapper-Spalte, lassen sich die zu verwendenden Algorithmen (sofern neue implementiert werden) auswählen. Des Weiteren können Einstellungen vorgenommen werden um die Verarbeitungsgeschwindigkeit zum Preis von Genauigkeit zu erhöhen. Hierbei lassen sich Werte für downsampling, die Anzahl der ctf-Level, die Voxelgröße (für Mapper) und die maximale Tiefe (für Mapper und Tracker), einstellen. Der downsampling-Wert entspricht einem Faktor um den die Seitenlänge des Eingabebilds geteilt wird, um die Berechnung zu beschleunigen. Die Anzahl der ctf-Level bestimmt die Anzahl der Ebenen der Gaußfilterpyramide. Hintergründe über diese Einstellungsmöglichkeiten sind in [4] zu finden. Ein Abschließend kann die berechnete Trajektorie, in Form einer Textdatei, abgespeichert werden. Die Textdatei beinhaltet eine Zeile pro Zeitschritt, die jeweils mit dem Zeitstempel in Sekunden versehen ist. Darauf folgt die errechnete Kameraposition und Lage, bezogen auf den Startpunkt, angegeben in kartesischen Koordinaten und Quaternionen.

Beispiel:

# estimated pose trajectory file # line format: timestamp tx ty tz qx qy qz qw 4597.977514 0.000000 0.000000 0.000000 0.000000 -0.000000 1.000000 -0.000000 4598.044457 0.000189 0.000080 0.001020 -0.000108 0.000035 1.000000 -0.000007 4598.111465 0.000425 0.001803 0.000214 -0.000014 0.000190 1.000000 -0.000236 [...]

Im Visualisierungsfenster (siehe Abb. 5–5) wird der Startpunkt der Kamera, die relative Position der Kamera zum Target und das durch den gewählten Mappingalgorithmus rekonstruierte 3D-Mesh, dargestellt.

Abb. 5–5: Visualisierungsfenster der Benutzeroberfläche des SF. Rekonstruktion aus RGB-D Bildern der Kinect v2

Zur weiteren Bearbeitung kann das 3D-Mesh exportiert werden. Dabei sind PLY, STL und VTK mögliche Dateitypen.

Unterhalb der Bedienbereiche werden die Farb- und Tiefenbilder angezeigt, welche zum aktuellen Zeitpunkt, von den jeweiligen Modulen verarbeitetet werden.


Seite 35

5.1.1.2 Bewegungsreichweite (Range of Motion)

Um die Bewegungsreichweite entlang der einzelnen Achsen (siehe Tab. 5–12) des RACOON-Labs zu veranschaulichen, wird das Gesamtkoordinatensystem der Anlage in Abb. 3–1 betrachtet. Dabei veranschaulicht Tab. 5–1 die Verfahrbarkeit entlang der elf Freiheitsgrade der Anlage, welche in Abb. 5–6 dargestellt werden. Die Bewegungsreichweiten entlang der Freiheitsgrade entsprechen dabei der möglichen Bewegung bis ein Anschlag erreicht ist.

Tab. 5–1: Bewegungsreichweite des RACOON-Labs aufgeschlüsselt entlang der Freiheitsgrade teilweise übernommen aus [32] und nachgemessen.

Parameter Servicer (von/bis) Target (von/bis)

Position

X [m] -0.3 / +2.7 0 / 0

Y [m] -1 / +1 0 / 0

Z [m] -1.3 / +0.05 0 / 0

Rollen um X [°] endlos -45 / +45

Nicken um Y [°] -90 / +90 -45 / +45

Gieren um Z [°] -90 / +90 endlos

Geschwindigkeit

Translatorisch [cm/s] >20 in X und Y; >5 in Z 0

Rotatorisch [°/s] >10 >10 um Z; >5 um X und Y

Zusätzlich zu den drei rotatorischen Freiheitsgraden, ist es dem Target möglich auf der C-Schiene verfahren zu werden und somit von 0 bis 180 Grad um die Y-Achse zu nicken und von -45 bis 45 Grad um die Z-Achse zu gieren.

Somit stehen dem Betreiber insgesamt elf bedienbare Freiheitsgrade für Servicer und Traget zur Verfügung. Drei translatorische und drei rotatorische Freiheitsgrade sind für den Servicer ansteuerbar. Die insgesamt fünf rotatorischen Freiheitsgrade des Targets, teilen sich auf in neigen, gieren und rollen des Targets, verfahren des Targets auf der C-Schiene und drehen der C-Schiene.

Abb. 5–6: Freiheitsgrade (engl.: Degrees of Freedom, DoF) der Anlage entnommen aus [31]


Seite 36

5.1.2 Satelliten-Mockup

Das momentan verwendete Satelliten-Mockup besteht aus einem Quader mit den Maßen 60 cm x 70 cm x 100 cm und zwei abgeschnittenen, seitlich angebrachten Solarzellen. Mit den Solarzellen erreicht das Mockup eine Breite von 160 cm. Die maximale Größe, die das Mockup haben darf beträgt 180 cm im Durchmesser (sphärisch) und das maximale Gewicht ist auf 30 kg beschränkt. Dabei ist die Größe durch den Durchmesser der C-Schiene, in der das Mockup rotiert, beschränkt.

Abb. 5–7: Mockup aus isometrischer Ansicht (links) und Mockups aus seitlicher Ansicht (rechts).

Um dem Mockup die Rotation entlang der fünf Freiheitsgrade zu ermöglichen, wurde diese über die Unterseite an eine C-förmige Schiene befestigt. Zum Nachteil wird diese Schiene, wie sie auf den aufgenommenen Tiefenbildern zu sehen ist, da sie keiner Struktur in einem realistischen OOS-Szenario im Weltraum entspricht.

Die Oberfläche des Mockups besteht aus verschiedenen Materialien die denen eines regulären Satelliten ähneln. Die verwendete Solarzelle entspricht einer generischen einlagigen Solarzelle. Sie ist jedoch nur auf einer Seite der Platte angebracht. Der Rest des Körpers ist mit einem Material beschichtet, dass MLI (Multi Layer Insulation) entsprechen soll. Besonders die silbrig glänzenden seitlichen Flächen (siehe Abb. 5–7), reflektieren einen Großteil des einfallenden Lichts, sodass sie einem planen Spiegel gleichen. Dieser hohe Reflexionsgrad der seitlichen Flächen, stellte sich als bei sämtlichen Versuchen als besondere Herausforderung für den Trackingalgorithmus heraus. Warum dies der Fall ist wird in 6.2 erläutert.

5.1.3 Sensoren

Für den derzeitigen Versuchsaufbau wurden zwei Kameras gewählt, denen es möglich ist Tiefenwerte für jeden Pixel aufzunehmen. Zusammen mit dem Sensorcomputer wurden die Kameras jeweils auf gegenüberliegenden Seiten der Servicer-Struktur angebracht. In Tab. 5–2 werden die wichtigsten Computerkomponenten des Sensorcomputer aufgelistet und in Abb. 5–8 ist die Servicer-Struktur abgebildet.


Seite 37

Tab. 5–2: Beschreibung der Computerkomponenten des Sensorcomputers entnommen aus [31] .

Komponenten Beschreibung

Prozessor Intel Core i5-5200U (dual core, 2.2 GHz – 2.7 GHz)

Arbeitsspeicher 16 GiB DDR3

Grafikkarte GeForce GTX 960 with 3 GiB GDDR5, 192 bit

Festplatte 256 GiB SSD

Abb. 5–8: Servicer Struktur mit den beiden Kamera Sensoren und dem Sensorcomputer

Die beiden Sensorsysteme werden im Folgenden vorgestellt:

5.1.3.1 Kinect v2

Einer der bekanntesten kommerziell verfügbaren RGB-D-Kameras ist die Kinect von Microsoft. Ursprünglich wurde sie als Eingabegerät zur Bewegungssteuerung für die Spielkonsole Xbox entwickelt. Aufgrund ihres günstigen Preises und ihrer globalen Verfügbarkeit, wurde ihr Einsatz auch in Forschungslaboren etabliert [33]. Im RACOON-Lab wird die aktuellste Version der Kinect, die Kinect v2, verwendet. Diese ist seit 2014 erhältlich und basiert auf dem Lichtlaufzeitverfahren (engl.: Time of Flight, ToF) zur Tiefenmessung [34]. Dabei wird die Entfernung über die gemessene Verzögerung des Wiedereintreffens von ausgesendeten Infrarotlichtpulsen ermittelt, welche durch die Umgebung reflektiert werde [4]. Somit wird für jeden Pixel ein Tiefenwert gemessen.

In Abb. 5–9 ist die verwendete Version abgebildet und in Tab. 5–3 sind die technischen Daten aufgelistet:


Seite 38

Abb. 5–9: Microsoft Kinect v2 RGB-D-Kamera [35]

Tab. 5–3: Technische Daten der Kinect v2, entnommen aus [4, 31, 36, 37]

Eigenschaft Wert

Hersteller Microsoft

Sensortyp RGB und Infrarot (IR)

Schnittstelle USB 3.0 und Stromanschluss

Farbbildauflösung Bis zu 1920 x 1080 px

Horizontales Farbbildsichtfeld 84,1 °

Vertikales Farbbildsichtfeld 53,8 °

Farbtiefe 24 bit

Tiefenbildauflösung 512 x 424 px

Horizontales Tiefensichtfeld 70,6 °

Vertikales Tiefensichtfeld 60 °

Tiefenwertgenauigkeit 13 bit

Bildwiederholrate 30 Hz (15 Hz/ im IR-Modus bei schlechten Lichtverhältnissen)

Minimale Tiefe 0,5 m

Maximale Tiefe 4,5 m

Genauigkeit 1 mm – 5 mm

Energieverbrauch ca. 15 W

5.1.3.2 ZED

Die ZED gilt, laut Angabe des Herstellers, als die weltweit erste 3D Kamera für Tiefenmessung und Bewegungsverfolgung [38]. Sie wurde 2015 veröffentlicht und berechnet Tiefeninformation mithilfe von zwei hochauflösenden RGB-Sensoren. Dabei werden zwei Bilder desselben Objekts von leicht versetzten Standpunkten aufgenommen und mit Hilfe der Epipolargeometrie, ein Disparitätsbild in Graustufen und schließlich das Tiefenbild mit einem Tiefenwert pro Pixel, errechnet. Die genaue Vorgehensweise bei der Berechnung eines Tiefenbildes aus zwei Bildern desselben Objekts aus leicht versetztem Standpunkt, mit Hilfe der Stereogeometrie, ist in [39] beschrieben. Die ZED ist weltweit inklusive eines Software Development Kits (SDK) und einer ausführlich dokumentierten Anwendungsprogrammierschnittstelle (engl.: application programming interface, API) erhältlich.

In Abb. 5–10 ist die verwendete Version abgebildet und in Tab. 5–4 werden die technischen Daten aufgelistet:

Abb. 5–10: ZED Stereokamera von Stereolabs [38]


Seite 39

Tab. 5–4: Technische Daten der ZED entnommen aus [31, 36, 38]

Eigenschaft Wert

Hersteller Stereolabs

Sensoren Stereo RGB

Schnittstelle USB 3.0

Farbbildauflösung 672 x 376 px 1280 x 720 px

1920 x 1080 px 2208 x 1242 px

Farbtiefe 32 bit

Sichtfeld (RGB und D) max. 110 Grad (Durchmesser)

Tiefenbildauflösung entspricht gewählter RGB Auflösung

Tiefenwertformat 32 bit

Bildwiederholrate Bis zu 100 Hz

Minimale Tiefe 0,7 m

Maximale Tiefe 20 m

Genauigkeit 0,4 mm – 1 mm

Energieverbrauch 19 W

Zu beachten ist, dass die hohe Bildrate von 100 Hz nur bei der geringsten Auflösung möglich ist. Die letztendlich für den Versuch verwendeten Kameraeinstellungen der Kameras, sowie die die intrinsischen Kameraparameter sind in Tab. 5–9.

5.1.4 Lichtquellen und Umgebung

Im Orbit erweisen sich die starken Kontraste, welche durch die schlechten Lichtverhältnisse und der Oberflächenbeschaffenheit der Satelliten entstehen, als eine Herausforderung für die verwendeten Rekonstruktionsalgorithmen [31]. Um diesen Zustand zu simulieren wurde im Zuge einer Bachelorarbeit am LRT ein Sonnensimulator entwickelt, welcher das Lichtspektrum der Sonne weitestgehend wiederspiegelt (siehe Abb. 5–11) [16]. Die Werte für Bestrahlungsstärke und Strahlungsleistung sind [16] entnommen, wobei die in der Arbeit angegebenen Referenzwerte für die Bestrahlungsleistung der Sonne nicht verwendet wurden.

In Abb. 5–11 (rechts) sind die Spektren im Bereich des sichtbaren Lichts der Sonne und des verwendeten Simulators dargestellt. Dabei erreicht die Metallhalogenid Lampe eine ähnliche Spektralverteilung wie die Sonne im optischen Bereich des Lichts bei einer Strahlungsleistung von etwa 575 Watt [16].

Die Strahlungsintensität des Simulators ( 5–1 ) aus 1 m Entfernung entspricht dabei jedoch nur etwa 28% ( 5–3 ) der Sonne ( 5–2 ). Der gewählte Wert für die Bestrahlungsstärke der Sonne entspricht der extraterrestrischen Solarkonstante (ETR ASTM E-490 Standard [40]).

𝐼𝑆𝑖𝑚𝑢𝑙𝑎𝑡𝑜𝑟 = 382,6419𝑊

𝑚2 ( 5–1 )

𝐼𝑆𝑢𝑛 = 1366,1𝑊

𝑚2 ( 5–2 )

𝐼𝑉𝑒𝑟ℎä𝑙𝑡𝑛𝑖𝑠𝑠 =𝐼𝑆𝑖𝑚𝑢𝑙𝑎𝑡𝑜𝑟

𝐼𝑆𝑢𝑛= 0,2801 ( 5–3 )


Seite 40

Der gesamte Sonnensimulator kann auf einer Schiene um Servicer und Target bewegt werden. Dadurch können verschiedene Lichteinfallwinkel realisiert werden. Somit wird der Anlage ein weiterer Freiheitsgrad hinzugefügt, welche die Position des Satelliten im Orbit, bzw. die mittlere Anomalie des Satelliten, beschreibt [31].

Abb. 5–11: Links zu sehen ist der Sonnensimulator des RACOON-Labs, entnommen aus [31], und rechts seine Spektralverteilung verglichen mit der Spektralverteilung der Sonne [40].

In einer parallel laufenden Arbeit [41] wurde ein Albedo-Simulator entwickelt, um zu überprüfen ob die von der Erde reflektierte Sonnenstrahlung, welche durch den Albedosimulator simuliert werden soll, eine Auswirkung auf die Rekonstruktionsqualität besitzt. Wie auch beim Sonnensimulator, ist die Lichtquelle des Albedo-Simulators eine Metallhalogenid Lampe, welche eine Strahlungsleistung von 250 W besitzt. Des Weiteren ist der Albedo-Simulator auf der gleichen Schiene wie der Sonnensimulator montiert und ist somit um Target und Servicer bewegbar. Da er zum Zeitpunkt der Versuchsreihen noch nicht fertiggestellt ist, wird er in keinem Versuch berücksichtigt.

Die Spektralverteilung des Erdalbedo-Simulators ist in mit verschiedenen Referenzwerten verglichen. Die Messdaten der Referenz wurden von der Universität Leipzig [42] ermittelt und in der parallel laufenden Semesterarbeit ausgearbeitet. Sie beziehen sich auf verschiedene Oberflächen der Erde mit unterschiedlichen Reflexionsgraden. Für genauere Informationen sei auf die Semesterarbeit von N. Reichenbach verwiesen [41].


Seite 41

Abb. 5–12: Spektralverteilung des Albedo-Simulators verglichen mit verschiedenen Referenzwerten.

Zudem sind über 90 % der Anlage mit schwarzen Vorhang überdeckt, der weniger als 1 % des einfallenden Lichts reflektiert [32]. Diese Vorkehrung soll gewährleisten, dass die Sensoren das zurückgeworfene Licht des Raums nicht registrieren, womit die gleiche Situation wie im Orbit, bei der sich der Satellit vor einem unendlich weit entfernten Hintergrund befindet, simuliert wird. Jedoch erhält in der Praxis vor Allem die Kinect v2 Tiefendaten des Raumes und von Befestigungsstrukturen der Anlage, was zu einer erheblichen Abnahme der Qualität hinsichtlich Positionserkennung führt. Der in 5.1.1.1 beschriebene Boxfilter ist herbei eine erhebliche Hilfe um störende Strukturen auszublenden und damit der Trajektorien-Berechnung, im Rahmen der in der Metrik beschriebenen Bewertungsparameter, erheblich zu verbessern (siehe 5.4.2).

5.2 EPOS

Folgende Vorstellung und Beschreibung der Anlage basiert auf [43] und [44], sowie auf eigenen Erfahrungen während des zweimonatigen Aufenthalts beim DLR.

5.2.1 Überblick

EPOS 2.0, eine robotische Hardware-in-the-Loop Anlage, befindet sich im Deutschen Raumfahrtkontrollzentrum (engl.: German Space Operations Center, GSOC) in Oberpfaffenhofen, Deutschland. EPOS 2.0 (im folgenden nur EPOS genannt), ist eine robotische Testanlage für die Simulation von Rendezvous und Docking (RvD) Prozessen. Sowohl Hardware, wie bspw. Kamerasensoren, als auch Software, bspw. für Guidance Navigation and Control-Systems (GNC), kann mit dem EPOS getestet, verifiziert und validiert werden. Die Anlage besteht im Wesentlichen aus zwei robotischen Armen, welche jeweils sechs Freiheitsgrade besitzen, einer 25 m langen Schiene auf der der Servicer-Roboterarm verfahren werden kann und einem computergestützten Überwachungs- und Kontrollsystem. Dadurch erlaubt das EPOS


Seite 42

2.0 sogar Echtzeit Simulationen von Docking- oder Bergungsprozessen [44]. Damit qualifiziert sich das EPOS ebenfalls als ideale Anlage für das gewählte OOS-Szenario.

In Abb. 5–13 ist Roboterarm 1 (Modell: KUKA KR100HA), auf dem der Servicer befestigt ist, links im Bild zu erkennen. Roboterarm 2 (Modell: KUKA KR240-2), auf dem das Target, in diesem Fall ein Satelliten-Mockup, befestigt ist, ist rechts im Bild zu sehen und die Schiene (Modell: KUKA KL1500), auf der sich Roboterarm 1 verfahren lässt, ist unten im Bild zu sehen [44].

Abb. 5–13: EPOS Anlage mit Scheinwerferlicht.

Um die gesamte Anlage ist ein Schutzzaun aufgebaut, der nur im geschlossenen Zustand, aus Sicherheitsgründen, den automatisierten Betrieb der Anlage erlaubt. In Abb. 5–14 ist der grundlegende Aufbau der Anlage für ein reguläres OOS-Szenario dargestellt.

Abb. 5–14: Aufbau der EPOS Anlage entnommen und abgeändert aus [44].


Seite 43

Die EPOS-Anlage besitzt im Vergleich zum RACOON-Lab eine höhere Komplexität was die Steuerung der Anlage betrifft. Daher wird sie im Folgenden kurz anhand eines zusätzlichen Unterkapitels erläutert:

5.2.1.1 Steuerungssysteme der Anlage

Die EPOS-Anlage besitzt drei verschiedene Steuerungsebenen, welche in Abb. 5–15 dargestellt sind und im Folgenden kurz beschrieben werden:

Abb. 5–15: Die drei verschiedenen Steuerungsebenen der EPOS-Anlage entnommen aus [43].

In der untersten Ebene, der lokalen Roboter Steuerung (engl.: Local Robot Control, LRC) werden die Achsen von jedem Roboter unabhängig voneinander in Echtzeit angesteuert. Diese Steuerungseinheit wurde vom Hersteller (KUKA) zur Verfügung gestellt. Die Ansteuerung jedes Roboterarms erfolgt dabei mit einer Befehlsrate von 250 Hz. Damit kann alle 4 ms ein Befehl erfolgen [44].

Eine Ebene höher wird die Gesamtanlage, im Anlagen Überwachungs- und Kontrollsystem (engl.: Facility Monitoring and Control, FMC), in Echtzeit gesteuert und überwacht. Auf dieser Ebene können vom Bediener, unter Anderem, sämtliche Parameter und Zustände der Anlage überwacht, protokolliert und kontrolliert werden [44]. Die Benutzeroberfläche des FMC ist in Abb. 5–16 dargestellt.


Seite 44

Abb. 5–16: FMC Benutzeroberfläche für Überwachung und Kontrolle der Simulation, entnommen aus [43].

Des Weiteren kann, wie in Abb. 5–17 abgebildet, die Bewegung der Roboter in Echtzeit visualisiert und überwacht werden.

Abb. 5–17: Visualisierung der Roboterbewegung entnommen aus [43].

Im Anwendungskontrollsystem (engl.: Application Control System, ACS) wird die eigentliche RvD-Simulation betrieben. Hier können szenariospezifische Modelle der Satellitendynamik in eine MATLAB/Simulink Umgebung implementiert werden. Die ausführbare Datei wird auf einen echtzeitfähigen Computer geladen, welchem es möglich ist über einen EtherCAT Bus mit dem FMC System zu kommunizieren. Die gewünschten Positionen müssen dabei alle 4 ms, wie von der LRC Einheit angefordert, kommuniziert werden [44].

Die Ansteuerung der Roboterarme erfolgt innerhalb verschiedener Koordinatensysteme. Die wesentlichen KS werden zum weiteren Verständnis kurz veranschaulicht:


Seite 45

Das Werkzeug-spezifische KS (engl.: Tool Coordinate System, TCS, siehe Abb. 5–18 links) ist ein kartesisches KS und hat seinen Ursprung im Zentrum des Werkzeug Flanschs. Jeder Roboterarm besitzt ein solches Werkzeug-KS. Das Sockel-KS (engl.: Base Coordinate System, BCS, siehe Abb. 5–18 mittig) ist ebenfalls ein kartesisches KS, dessen Ursprung sich jeweils im Zentrum der Sockel der beiden Roboterarme befindet. Ebenfalls eines für jeden Roboter. Auch das globale KS (engl.: Global Coordinate System, GLCS, siehe Abb. 5–18 links) ist ein kartesisches KS. Die XY-Ebene des GLCS ist parallel zur XY-Ebene des BCS des zweiten Roboterarms. Dabei ergibt sich die Z-Achse des GLCS aus der Schnittgeraden zwischen der XZ-Ebene des BCS von Roboter 1 und der XY-Ebene von Roboter 2. Der Ursprung befindet sich 1500 mm über der XY-Ebene des Sockel-KS des zweiten Roboterarms (KUKA KR240-2) auf der beschriebenen Z-Achse.

Abb. 5–18: KS der Anlage: TCS links; BCS mittig; GLCS rechts. Entnommen aus [44]

Des Weiteren ist eine Ansteuerung in Gelenkkoordinaten (engl.: Ideal Robot Joint Coordinates, IJT) möglich. Dadurch kann einfach der gewünschte Winkel, in dem sich jedes Gelenk befinden soll, eingestellt werden. Die verschiedenen verstellbaren Gelenke eines Roboterarms sind in Abb. 5–19 dargestellt.

Abb. 5–19: IJT entnommen aus [43]

Zu Letzt, kann die Anlage ebenfalls in einem Clohessy Wiltshire (CLW) KS angesteuert werden, welches speziell für RvD Simulationen nützlich werden kann, da es seinen Ursprung im Schwerpunkt des Targets besitzt. Für genauere Informationen zu sämtlichen KS sei auf [43, 44] verwiesen.


Seite 46

5.2.1.2 Benutzeroberfläche

Um die Anlage zu bedienen gibt es im Wesentlichen drei verschiedene Möglichkeiten:

Eine sogenannte asynchrone Kommando-Schnittstelle (engl.: Asynchronous Command Interface), welche eine vorgegebene Trajektorie von einer auf dem FMC-System gespeicherten Datei einliest. Der Vorteil hierbei ist, dass sich der Betreiber keine Sorgen um die stetige Befehlserteilung machen muss. Er kann bereits im Voraus eine Trajektorie bestimmen, welche dann abgefahren werden kann. Dabei muss die Trajektorie als ASCII Datei mit folgender Struktur erstellt werden:

Jede Zeile enthält einen int16 Wert gefolgt von 22 double Werten getrennt durch ein Leerzeichen. Dabei ist Jede Zeile ein Kommando und der Abstand zwischen zwei Kommandos beträgt 4 ms. Die Bedeutung jeder Spalte ist in Tab. 5–5 erläutert.

Tab. 5–5: Definition der Parameter für asynchrones Kommandieren, entnommen aus [43]

Spalte Nr. Parameter Datentyp Beschreibung Anmerkung

1 Ref_Coord 1 Int 16 Referenz-KS 1 = CLW 2 = GLCS 3 = IJT

2-8 CMD Rob1 7 double Position und Lage Roboter 1

9-15 CMD Rob2 7 double Position und Lage Roboter 2

16-22 CMD POV 7 double Position und Lage eines Bezugssystems

Wird nur für CLW KS benutzt

23 Data_lin 1 double Position von Roboter 1 auf der Schiene

Eine zweite Bedienmöglichkeit bietet die synchrone Kommando-Schnittstelle (engl.: Synchronous Command Interface). Hierbei wird mit Hilfe des EtherCAT Protokolls die Anlage über den ACS_RT (engl.: Real time, RT) Computer befehligt. Dabei erhält der Echtzeit-Computer Trajektorien Dateien, welche die gewünschte Position enthalten und sendet Trajektorien Daten zurück, welche die von den Robotern gemeldete Position enthalten. Dabei werden gesendete und empfangene Daten im gleichen KS referenziert. Die Struktur der Eingabe ist hierbei ähnlich zu der in Tab. 5–5 beschriebenen Struktur. Für ausführliche Informationen sei auf [43] verwiesen.

Zu Letzt besteht die Möglichkeit die EPOS-Anlage über eine manuelle Kontrolleinheit (engl.: Manual Control Unit, MCU) zu bedienen. Die Kontrolleinheit erlaubt KS und Roboter auszuwählen und jede Achse separat anzusteuern und auszurichten. Die MCU ist in Abb. 5–20 dargestellt.


Seite 47

Abb. 5–20: MCU steht im Kontrollraum der Anlage zur Verfügung.

Hierbei ist zu bedenken, dass bei der Ansteuerung über das MCU immer noch die FMC-Steuereinheit dazwischengeschaltet ist. Um diese zu umgehen, kann das Kuka Control Panel (KCP) benutzt werden.

5.2.1.3 Bewegungsreichweite

Die EPOS-Anlage weist durch den großen Raum, der ihr zur Verfügung steht, und den insgesamt zwölf Freiheitsgraden der beiden Roboterarme ein weites Spektrum an Bewegungsmöglichkeiten auf. Dieses Spektrum wird in Tab. 5–6 angegeben.

Tab. 5–6: Bewegungsreichweiten und Fähigkeiten der EPOS-Anlage dargestellt im globalen KS entnommen aus [44]

Parameter Roboterarm 1 (von/bis) Roboterarm 2 (von/bis)

Position

X [m] -2.5 / +24.5 -2.5 / +2.5

Y [m] -2.5 / +2.5 -1.0 / +4.0

Z [m] -0.5 / +1.2 -0.5 / +1.5

Rollen [°] -300 / +300 endlos

Nicken [°] -90 / +90 -90 / +90

Gieren [°] -90 / +90 -90 / +90

Geschwindigkeit

Translatorisch [cm/s] 2 2

Rotatorisch [°/s] 180 180

Die Schiene auf der Roboterarm ein verfahren wird, besitzt einen translatorischen Freiheitsgrad und kann maximale Geschwindigkeiten von 1.45 m/s erreichen.

Die Genauigkeit der Anlage muss speziell bei Docking oder Bergungsszenarien im Millimeterbereich liegen. Sie wurde mit Hilfe eines Leica Lasertrackers von einem externen Unternehmen ermittelt. Insgesamt wurde eine Positionsgenauigkeit von 1.56 mm und eine Orientierungsgenauigkeit von 0.2 ° gemessen [44].


Seite 48

5.2.2 Satelliten-Mockup

Das Satelliten-Mockup ist auf Roboterarm 2 montiert und in Abb. 5–21 abgebildet. Die Grundform entspricht einem Sechseck aus dem ein Zylinder ragt. Auf der Spitze des Zylinders ist eine achteckige Struktur befestigt. Die sechs seitlichen Flächen der Grundform sind mit Ausschuss Solarzellen eines Satellitenherstellers bedeckt. Der Zylinder sowie die obere Fläche sind mit MLI-Folie überzogen. Darüber hinaus sind weitere Strukturelemente aus Aluminium zu sehen.

Abb. 5–21: Aktuelles Mockup der EPOS-Anlage

5.2.3 Sensoren

Zur Zeit des Aufenthalts beim DLR waren zwei verschiedene Sensorsysteme am Sensorboard auf Roboterarm 1 montiert. Zwei CCD-Sensoren (engl.: charge coupled device) und ein Photomischdetektor auch PMD-Sensor genannt (engl.: Photonic Mixing Device). Auf dem Sensorboard ist kein Sensorcomputer montiert. Es besteht jedoch die Möglichkeit dazu.


Seite 49

Abb. 5–22: Sensorboard des Servicers der EPOS-Anlage

Des Weiteren ist ein Ethernet-Switch und die Stromversorgung auf dem Sensorboard montiert, wie in Abb. 5–22 zu sehen ist.

Die beiden Sensoren werden im Folgenden kurz vorgestellt, wobei der Fokus auf dem PMD-Sensor liegt, da die CCD-Sensoren bei momentaner Konfiguration nicht als Stereokameras agieren und somit keine Tiefendaten generieren.

5.2.3.1 CCD-Kamera

CCD-Sensoren sind lichtempfindliche elektronische Bauelemente die ein zweidimensionales Intensitätsbild erzeugen können [44]. Der verwendete CCD-Sensor ist eine grau-skalierte Prosilica GC-655M mit einer Auflösung von 640 x 480 px.

Abb. 5–23: Prosilica GC-655M entnommen aus [44]

Das generierte Bild wird verwendet, um mit einem vereinfachten CAD-Modell des Mockups die relative Position des Servicers zum Target in Echtzeit zu bestimmen


Seite 50

und damit die Trajektorie zu errechnen. In Abb. 5–24 ist wurden die Kanten des Mockups erfolgreich erkannt, damit ist es möglich die Position des Servicers zum Target anhand der Größe des angepassten CAD-Modells zu errechnen.

Abb. 5–24: Beispiel eines Bildes aufgenommen von der Prosilica GC-655M, in dem die Kanten erfolgreich erkannt wurden und das CAD-Modell passend darüber gelegt wurde.

Während des Aufenthalts beim DLR, wurden keine Versuche mit der CCD-Kamera durchgeführt, da kein Algorithmus zur Lage und Positionsschätzung eines unbekannten Objekts implementiert war. Daher wird an dieser Stelle nicht weiter auf die CCD-Kamera eingegangen.

5.2.3.2 PMD-Kamera

Ein Photomischdetektor ist ein optischer Sensor dessen Funktionsprinzip, ähnlich wie die Kinect v2, auf dem Lichtlaufzeitverfahren basiert. Dabei wird die Phasenverschiebung zwischen dem emittierten und dem empfangenen, zuvor von einem Objekt reflektierten, Infrarotlicht gemessen und daraus eine Distanz errechnet. Mit dieser Information kann ein Tiefenbild mit einem Tiefenwert pro Pixel generiert werden [44]. Um das eigene ausgesendete IR Licht von dem von anderen Lichtquellen zu unterscheiden, werden meist Filter vor die Sensoren platziert die alle störenden Frequenzen außer die entsendete herausfiltern sollen. Die von der EPOS-Anlage verwendete PMD-Kamera ist ein Prototyp, welcher von Bluetechnix speziell für das DLR entwickelt wurde. Das in Abb. 5–25 abgebildete Modell Argos3D-IRS1020 DLR Prototype (im Folgenden auch Argos3D genannt) ist unter anderem ausgestattet mit höherer Reichweite und Auflösung als die verwandten Serienmodelle Arogs3D-P321 oder Argos3D-P320 (siehe [45]). Des Weiteren enthält die Argos3D-IRS1020 DLR Prototype einen CMOS Sensor, welcher ein Intensitätsbild aufnehmen lässt, welches ebenfalls ausgegeben werden kann.

Abb. 5–25: Argos3D-IRS1020 DLR Prototype von Bluetechnix entnommen aus [44]


Seite 51

In Abb. 5–26 wurde aus den gemessenen Intensitäts- und Tiefenwerten (siehe Tab. 5–11 Versuch 19), mit Hilfe von MATLAB, ein Graustufen- und Tiefenbild erstellt.

Abb. 5–26: Links Graustufenbild aus Intensitätswerten und rechts Tiefenbild aus Tiefenwerten der PMD-Kamera. Aufnahme aus 4 m Entfernung.

Da es sich bei dem verwendeten PMD-Kamera Modell um einen Prototyp handelt, sind die vorhandenen Technischen Daten begrenzt. Daher sind keine Informationen zur Genauigkeit der Tiefenwerte vorhanden. Sämtliche verfügbaren technischen Details wurden in Tab. 5–7 zusammengefasst.

Tab. 5–7: Technische Daten der Argos3D-IRS1020 DLR entnommen aus [46–49]

Eigenschaft Wert

Hersteller Bluetechnix

Sensortyp Infrarot

Schnittstelle Gigabit ETH

Wellenlänge 850 nm

Auflösung 352 x 288 px

Horizontales Sichtfeld 28.91 °

Vertikales Sichtfeld 23.45 °

Bildwiederholrate 20 fps

Bittiefe Tiefenbild 16 Bit

Energieverbrauch 6 W

5.2.4 Lichtquellen und Umgebung

Um Bestrahlungsintensität und Spektrum der Sonne zu reproduzieren wurde ein leistungsstarker Scheinwerfer für die EPOS-Anlage beschafft. Dabei sollte die Bestrahlungsstärke aus ca. 5 m Entfernung 1 kW/m^2 betragen und eine ähnliche Spektralverteilung, im sichtbaren Wellenlängenbereich, wie die Sonne außerhalb der Erdatmosphäre erreicht werden [43]. Der ARRIMax18/12 ausgestattet mit einer 12 kW Halogen-Metalldampflampe erfüllt diese Anforderungen [43]. Die Lampe ermöglicht einen Lichtstrom von 1.15 Mlm. Der Scheinwerfer wird standardmäßig mit 5 m Abstand zum Target aufgebaut.


Seite 52

Der Scheinwerfer und die zugehörige Spektralverteilung sind in Abb. 5–27 dargestellt. Als Referenzspektrum wurde wieder die ASTM E-490 Standard Bestrahlung außerhalb der Erdatmosphäre angegeben [43]. Des Weiteren sind die Spektralverteilungen des Scheinwerfers aus 7 m und 10 m dargestellt.

Abb. 5–27: Spektralverteilung (rechts) der ARRIMax18/12 (Scheinwerfer links) aus 7 m und 10 m Entfernung, entnommen aus [43]. ETR ASTM E-490 als Referenz.

Der Hintergrund ist genau wie im RACOON-Lab mit einem schwarzen Molton-Vorhang bedeckt.

Dem Scheinwerfer ist zwar möglich das Ziel mit Hilfe eines Neigungs- und Schwenkmechanismus zu verfolgen, er kann jedoch nicht aktiv verfahren werden um einen veränderten Lichteinfallwinkel zu erzeugen.

5.3 Vergleich der Anlagen

RACOON-Lab und EPOS bieten die Möglichkeit Nahbereichsnavigation des OOS softwaregestützt zu simulieren. Das EPOS besitzt darüber hinaus noch die Möglichkeit Docking- und Bergungsmanöver realistisch nachzustellen. Betrachtet man nur das beschriebene Szenario und lässt Docking und Bergungsmanöver außen vor, ähneln sich die Anwendungsgebiete der beiden Anlagen sehr. Um für zukünftige Projekte in Kooperation mit dem DLR zu entscheiden, welche Anlage für welche Szenarien die geeignetere ist, werden im Folgenden die beiden Anlagen anhand einiger Faktoren verglichen. Diese Faktoren wurden aus eigenen Erfahrungen, welche während verschiedenen Testreihen mit den Anlagen gewonnen wurden, erschlossen und auf Wunsch von Dr. H. Benninghoff, sowie Herr M. Dziura angepasst.


Seite 53

5.3.1 Komplexität

Die Komplexität des gesamten Systems wirkt sich maßgeblich auf die Einarbeitungszeit aus und kann Hindernis für die Durchführung von verschiedenen Testkampagnen sein. Speziell für kurze Projekte, wie studentische Arbeiten, ist eine geringe Einarbeitungszeit von Vorteil. Gleichzeitig sind jedoch angemessene Sicherheitsvorkehrungen und eine umfangreiche Funktionsauswahl erwünscht, was die Komplexität wiederum erhöht. Eine gut umgesetzte Benutzeroberfläche kann es jedoch schaffen ein komplexes System für den jeden Benutzer zugänglich zu machen. Dies ist beiden Anlagen zum Teil gelungen. Die Folgenden Aussagen beruhen dabei auf eigenen Erfahrungen im Umgang mit den beiden Anlagen.

Da das RACOON-Lab regelmäßig von Studenten benutzt wird, ist eine intuitive Benutzeroberfläche eine Priorität bei der Weiterentwicklung dieser. Der sichere Umgang mit der Benutzeroberfläche für die Ansteuerung des Sensorcomputers (beschrieben in 5.1.1.1), war bereits nach wenigen Stunden Einarbeitungszeit möglich. Als problematischer stellt sich jedoch die Ansteuerung der einzelnen Achsen über die LabVIEW Schnittstelle heraus. Hierbei ist das Grundprinzip einfach, da jede Achse separat ausgewählt und angesteuert werden kann. Momentan mangelt es jedoch an einer Übersetzung von der verwendeten softwarespezifischen Schritte-Einheit in Meter für translatorische Achsen oder Grad für rotatorische Achsen. Dies erhöhte den benötigten Zeitaufwand für Versuche maßgeblich. Das neu installierte OptiTrack-System soll nun die genaue Umrechnung von Schritten in Meter bzw. in Grad ermöglichen. Insgesamt ist das Grundprinzip jedoch einfach und schnell zu verstehen. Die Bedienung der Anlage sollte jedoch nie alleine durchgeführt werden um eine ausreichende Überwachung eines Versuchs zu gewährleisten.

Die EPOS-Anlage stellt ein insgesamt komplexeres System dar, dies wird schon durch die drei Ebenen des Steuerungssystem (siehe 5.2.1.1) verdeutlicht. Zwar bietet die Möglichkeit einer asynchronen, synchronen sowie manuellen Benutzung der Anlage eine vielseitige und flexible Bedienung, jedoch ist für jede dieser Bedienmöglichkeiten ein gewisses technisches Verständnis der Anlage erfordert. So wird bei Testkampagnen Externer die Anlage stets von den zuständigen Arbeitskräften des DLR betätigt, da für die Bedienungserlaubnis der Anlage zunächst ein Kurs belegt werden muss. So wurde auch während dieses Austausches keine selbstständige Arbeit an der Anlage durchgeführt. Um die einzelnen Subsysteme der Anlage zu bedienen (PMD-Sensor, Überwachung, Befehlserteilung), waren stets zwei bis drei Mitarbeiter der Projektgruppe nötig.

5.3.2 Integrierbarkeit neuer Systeme

Unter diesem Faktor ist zu verstehen, welche Möglichkeiten bestehen neue Systeme, wie bspw. neue Tiefensensoren oder Mockups, aber auch neue Software, in die Anlagen zu integrieren. Dies ist besonders für zukünftige Projekte von Bedeutung, bei denen die Untersuchung von verschiedenen Sensorsystemen im Vordergrund stehen könnte.

Bei der Servicer-Struktur (siehe Abb. 5–8) des RACOON-Labs sind generell zwei Positionen für Sensorsysteme vorgesehen, welche momentan beide von der ZED und der Kinect v2 eingenommen werden. Des Weiteren kann ein Sensorcomputer


Seite 54

montiert werden, was momentan der Fall ist. Darüber hinaus sind keine weiteren Plätze für weitere Systeme vorgesehen. Das integrieren weitere Systeme, bspw. ein weiterer Sensor, verlangt einen gewissen Aufwand, da erst angepasste Befestigungsmechanismen konzipiert werden müssten.

Das Sensorboard der EPOS-Anlage erlaubt hierbei deutlich mehr Flexibilität. Eine etwa 700 x 700 mm große Lochplatte mit M6 Gewinde, bietet viel Platz und eine einfache Fixiermöglichkeit für Befestigungsmechanismen [44]. Darüber hinaus, besteht die Möglichkeit die oberste Platte zu entfernen, um eine weitere Lochplatte freizugeben. Dies gewährleistet einen schnellen Wechsel zwischen verschiedenen Systemen, ohne die Kameras erneut kalibrieren zu müssen.

Bei der Integrierung neuer Mockups, ist das RACOON-Lab hauptsächlich durch die C-Schiene auf einen sphärischen Durchmesser von 1,8 m und einem Gewicht von bis zu 30 kg eingeschränkt [32]. Roboterarm 2 der EPOS-Anlage besitzt eine 100 x 100 mm große Lochplatte mit M6 Gewinde auf der ein maximal 240 kg schweres Mockup platziert werden kann. Beschränkungen bezüglich der Größe des Mockups sind nicht explizit gegeben, jedoch sollte das Mockup nicht größer als 4 m sein, da es sonst mit dem Boden kollidiert. [43].

Auch die Möglichkeit zur unkomplizierten Integration neuer Software, wie beispielsweise Analysetools oder Algorithmen, ist eine wichtige Eigenschaft einer HIL-Anlage. Auf den Sensorcomputern des RACOON-Labs, sowie auch der EPOS-Anlage ist dies möglich. Dabei sollte die zu installierende Software, für die EPOS-Anlage, in C++ oder Simulink programmiert und auf einem Linux basierten Betriebssystem ausführbar sein. Der Sensorcomputer des RACOON-Labs wird mit Windows betrieben. Daher muss die Software mit Windows kompatibel sein.

5.3.3 Mockup Form und Materialien

Das Satelliten-Mockup ist ein entscheidender Faktor warum die Testergebnisse der Tiefenbildkameras nicht quantitativ miteinander verglichen werden konnten. Vor allem die Materialien an den sichtbaren Oberflächen und die Form des Mockups sind dabei hervorzuheben. Das Mockup der EPOS-Anlage besitzt Solarzellen, welche bei sämtlichen Versuchen nur wenig Licht im IR-Bereich reflektierten. Das erschwert die Generierung von Tiefendaten für den PMD-Sensor, der darauf angewiesen ist mit der Phasenverschiebung des reflektierten Lichts, die Distanz des Objekts zu bestimmen. Tiefendaten konnten nur von den Aluminium Strukturen und Kanten zwischen den Solarzellen gewonnen werden, wie in Abb. 5–26 zu erkennen ist (dunkelblauen Pixeln ist dabei kein Tiefenwert bzw. Null zugeordnet). Derartige Solarzellen sind nicht auf dem Mockup des RACOON-Labs befestigt. Daher ist an dieser Stelle kein Vergleich der Tiefensensoren angebracht.

Die Mockups beider Anlagen besitzen Stellen welche mit MLI oder mit einem ähnlichen Material überzogen sind. Speziell die silbrige Seite des RACOON-Lab Mockups ist dabei problematisch, da sie praktisch einem Spiegel gleicht. Die Problematik dieser stark reflektierenden Oberfläche ist in 6.2 genauer dokumentiert.

Ein nicht erprobter aber potentiell sehr limitierender Faktor könnte die Größe des Mockups darstellen. Die PMD-Kamera musste auf 4 m Abstand zum Mittelpunkt des Mockups herangefahren werden, um verwertbare Tiefenwerte zu erhalten (diese Erkenntnis war entgegen der Erwartungen, da der von Bluetechnix entwickelte


Seite 55

Prototyp eine größere Reichweite versprach). Bei dieser Distanz konnte jedoch nicht mehr das komplette Mockup abgebildet werden, daher stellen sämtliche Aufnahmen nur den unteren Solarzellen behafteten Teil des Mockups dar. Dies könnte dazu führen, dass man einen Kompromiss eingehen muss, ob man das gesamte Objekt im Sichtfeld haben will oder einen geringeren Abstand wählen will, um verwertbare Tiefenbilder zu erzeugen. Kameras wie die Kinect v2 oder die ZED haben bei größeren Distanzen im RACOON-Lab einen erheblichen Abfall in ihrer Performance (siehe 6.1.1) gezeigt. Daher könnte, abhängig von Sichtfeld der Kameras, eine Aufnahme des kompletten Mockups in der EPOS-Anlage für die Kinect v2 oder die ZED problematisch sein.

5.3.4 Lichtverhältnisse

Bezüglich der Lichtverhältnisse sind entscheidende Unterschiede zwischen den beiden Anlagen festzustellen. Beide Anlagen besitzen Sonnensimulatoren, welche der Spektralverteilung der Sonne sehr nahekommen. Dabei verfügt der ARRIMax18/12 Scheinwerfer der EPOS-Anlage jedoch eine höhere Bestrahlungsstärke von 1 kW/m2 aus 5 m Entfernung als der Sonnensimulator des RACOON-Labs. Betrachtet man nur das Spektralverteilung der Sonnensimulatoren, sind realistischere Lichtverhältnisse in der EPOS-Anlage gegeben.

Jedoch verfügt das RACOON-Lab über die Möglichkeit den Sonnensimulator auf einer Schiene zu verfahren. Diese Fähigkeit der Anlage erlaubt den Lichteinfallwinkel der Sonnenstrahlung zu untersuchen. Dadurch ist es möglich die sich über einen Orbit ändernde Sonnenbestrahlung zu simulieren.

Beide Anlagen verfügen über einen Molton-Vorhang der nahezu kein Licht reflektiert. Auffällig war jedoch, dass die Strukturen der C-Schiene des RACOON-Labs nicht durch den Vorhang verdeckt werden und dadurch eine potentielle Fehlerquelle bei der Positionsverfolgung darstellen. Die EPOS-Anlage verfügt insgesamt über weniger störende Strukturen.

Zu Letzt gilt zu erwähnen, dass ein Albedo-Simulator für das RACOON-Lab entwickelt wird. Zukünftige Testreihen sollen ergeben, ob das zusätzliche Licht des Albedo-Simulators eine Auswirkung auf die Rekonstruktionsgüte besitzt. Ist dies der Fall, so ist dem RACOON-Lab ein Vorteil bei der Erzeugung realistischer Lichtverhältnisse zuzusprechen.

5.3.5 Genauigkeit

Um sich sicher zu sein, dass die angesteuerten Koordinaten auch zufriedenstellend ausgeführt werden, ist eine hohe Genauigkeit erforderlich. Dabei ist Genauigkeit im Rahmen von Position, Lage und Geschwindigkeit zu verstehen.

Um die Genauigkeit einer Anlage zu messen, werden meist kostspielige Lasermesssysteme benötigt. Als kostengünstigere Alternative nutzt das RACOON-Lab das bereits beschriebene OptiTrack-System, welches eine Messgenauigkeit im Millimeterbereich liefern kann, um zukünftig die Genauigkeit der Anlage festzustellen. Momentan sind jedoch noch keine Genauigkeitswerte der Anlage vorhanden. Während verschiedener Testreihen wurde lediglich festgestellt, dass die Drehgeschwindigkeit der Endlosachse des Targets stark oszilliert und letztendlich etwa 0.15 °/s unterhalb des eingestellten Wertes liegt. Es handelt sich hierbei jedoch


Seite 56

nur um eine qualitative Beobachtung. Während der Versuche wurde diese Ungenauigkeit jedoch berücksichtigt. Durch Messungen mit dem OptiTrack-System konnte somit die tatsächliche Geschwindigkeit festgestellt werden. Das OptiTrack-System soll in Zukunft als Analysetool dienen, mit dem ein Referenzdatensatz für die genaue Position von Servicer oder Target im gewählten KS generiert werden soll. Zum jetzigen Zeitpunkt kann die im Rahmen dieser Arbeit erstellte Metrik als Analysetool verwendet werden.

Die EPOS-Anlage wurde genauestens vermessen und bietet hohe Genauigkeit für Position und Lage (in Tab. 5–8 und 5.2.1.3 aufgeführt). Zusätzlich steht durch die genaue Vermessung der Anlage stets ein Referenzdatensatz der Positionen der Roboter im gewählten KS als Analysetool für Experimente zur Verfügung.

5.3.6 Fazit

Durch ihre verschiedenen Eigenschaften qualifizieren sich die beiden Anlagen für Testkampagnen mit jeweils unterschiedlichen Szenarien.

Offensichtlich, eignet sich die EPOS-Anlage für Szenarien bei denen der Anflug aus größeren Distanzen (bis zu 25 m) erforderlich ist. Dies kann im RACOON-Lab selbst durch Skalierung des Mockups nicht erreicht werden. Um Sensoren mit einer Reichweite von über 5 m zu testen muss daher die EPOS-Anlage verwendet werden.

Für den Fall, dass externe Benutzer verschiedene Arten von originalgetreuen Mockups in die Anlage integrieren wollen, sind im RACOON-Lab, gewissen Restriktionen bezogen auf Form und Größe des Objekts durch die C-Schiene zu beachten. Die EPOS-Anlage erlaubt durch ihre Weitläufigkeit und ihren Freiraum um Roboterarm 2, nahezu beliebige Formen und Größen von Objekten zu installieren.

Durch die enorme Größe der EPOS-Anlage, schließt sich jedoch eine verfahrbare Lichtquelle, wie im RACOON-Lab, aus. Szenarien bei denen ein flexibler Lichteinfallwinkel nötig ist, sind daher im RACOON-Lab durchzuführen.

Auch ein realistischere Orbit-Simulation, bezogen auf die Lichtverhältnisse, ist im RACOON-Lab möglich, da der Sonnensimulator und der Albedo-Simulator den entsprechenden Einfallwinkel für jede Position des Objekts im Orbit darstellen lassen.

Zieht man jedoch in Betracht externe Sensoren im RACOON-Lab zu installieren ist dies mit erheblichem Aufwand verbunden, da keine Strukturen dafür vorgesehen sind. Daher empfiehlt sich die EPOS-Anlage für studentische Austauschprojekte, da sich externe Sensoren leicht auf die Lochplatte montieren lassen.

Bei Austauschprojekten muss jedoch genügend Einarbeitungszeit gewährleistet sein, da die EPOS-Anlage durch ihre verschiedenen Steuerungs- und Bedienebenen eine höhere Komplexität als das RACOON-Lab aufweist. Mit einem funktionsfähigen Analysetool und Referenzposition durch das OptiTrack-System, bietet das RACOON-Lab eine für unerfahrene Nutzer intuitivere Benutzeroberfläche zur Bedienung und Überwachung.


Seite 57

Um den Vergleich abzuschließen werden die wesentlichen technischen Parameter übersichtlich in Tab. 5–8 zusammengefasst.

Tab. 5–8: Vergleichstabelle der beiden Anlagen

Parameter RACOON-Lab EPOS

Ansteuerbare Freiheitsgrade

6(Servicer)+5(Target) +1(Sonne)+1(Albedo)=13

6(Servicer)+6(Target) +1(Schiene)=13

Koordinatensysteme Anlagen KS, Kamera KS, OptiTrack KS

TCS, BCS, GLCS, IJT, IDC, CLW

Trans Bewegungsreichweite Servicer [X,Y,Z]

3 m x 2 m x 1.305 m 27 m x 5 m x 1.7 m

Trans Bewegungsreichweite Target [X,Y,Z]

0 m x 0 m x 0 m 5 m x 5 m x 2 m

Rot Bewegungsreichweite Servicer [Rollen, Nicken, Gieren]

endlos, 180 °, 180 ° endlos, 180 °, 180 °

Rot Bewegungsreichweite Target [Rollen, Nicken, Gieren]

90 °, 90 °, endlos 600 °, 180 °,180 °

RGB-D Sensoren Kinect v2 ZED Argos3D-IRS1020 DLR

Schnittstelle USB 3.0 und Stromanschluss

USB 3.0 Gigabit ETH

Sensortyp RGB und IR Stereovision Infrarot

Mockup Skalierung 1:4 1:1

Hintergrund Molton-Vorhang Molton-Vorhang

Sonnensimulator Metallhalogenid Lampe ARRIMax18/12

Bestrahlungsstärke 385 W/m2 aus 1 m Distanz 1000 W/m2 aus 5 m Distanz

Strahlungsleistung 575 W 12 kW

Albedosimulator Metallhalogenid Lampe nicht vorhanden

Strahlungsleistung 250 W -

5.4 Versuchsdurchführung an beiden Anlagen

Um die Anwendbarkeit der Metrik in der Praxis zu gewährleisten wurden mehrere Versuchsreihen am RACOON-Lab und der EPOS-Anlage durchgeführt. So konnten Trajektorien, errechnet aus den Tiefenbildern verschiedener Sensoren, bei unterschiedlichen Umgebungsbedingungen bewertet werden. Dabei wurden zunächst Vorversuche durchgeführt, um die Einflussfaktoren einzugrenzen. Anschließend folgte die Hauptversuchsreihe, welche hauptsächlich am RACOON-Lab durchgeführt wurde.

5.4.1 Vorversuchsreihe

Bei der Vorversuchsreihe ging es hauptsächlich um das Einarbeiten in die Funktionsweisen der Anlagen und Festlegen von Rahmenbedingungen für die einzelnen Einflussfaktoren. Beispielsweise konnte festgestellt werden, dass Rotationsgeschwindigkeiten unterhalb von 1 °/s nicht mit dem aktuellen Sensorcomputer durchführbar sind, da der Arbeitsspeicher bei einer Bildwiederholrate von 30 fps etwa 10800 Bilder zwischenspeichern müsste [31]. Die vorhandenen 16 GB Arbeitsspeicher reichen jedoch dafür nicht aus. Es bestand die Annahme, dass der Trackingalgorithmus mit mehr Bildern, also mehr Information, pro


Seite 58

Sekunde ein besseres Ergebnis erzielen könnte. Da die minimale Rotationsgeschwindigkeit durch den Arbeitsspeicher des Sensorcomputers auf 1 °/s limitiert ist, wurde diese Konfiguration als Vergleichswert für höhere Geschwindigkeiten ausgewählt. Diese Art von technischen Limitierungen konnten in der Vorversuchsreihe festgestellt und in der Hauptversuchsreihe berücksichtigt werden.

Des Weiteren konnte während der Vorversuchsreihe festgestellt werden, dass die Startposition des Targets keine eindeutig bewertbare Auswirkung auf die Qualität der errechneten Trajektorie besitzt. Startet die Aufnahme mit Blick auf die stark reflektierende silbrige Folie (siehe Abb. 5–7 rechts), wird in der Regel eine schlechtere Trajektorie in Bezug auf den Drift erhalten. Diese Ergebnisse waren jedoch nicht quantifizierbar. Für die Hauptversuchsreihe wurde versucht, die Aufnahme näherungsweise von der Position zu starten, welche in Abb. 5–7 (links) zu sehen ist. Dadurch, dass die Aufnahme jedoch mit einer variablen Verzögerung startet konnte dies nicht immer gewährleistet werden.

Auch die Umdrehungsrichtung schien in den Vorversuchen keine nennenswerte Auswirkung auf die Qualität der Trajektorie zu besitzen. Daher wurde dieser Einflussfaktor während der Hauptversuchsreihe nicht beachtet.

Auch an der EPOS-Anlage wurde ein Vorversuch durchgeführt, um mit den Rahmenbedingungen vertraut zu werden.

Sämtliche Testergebnisse basieren ausschließlich auf Erkenntnissen aus der Hauptversuchsreihe, welche im Folgenden ausführlich behandelt wird.

5.4.2 Hauptversuchsreihe

In der Hauptversuchsreihe wurden sämtliche Einflussfaktoren auf ihren Einfluss auf die Rekonstruktionsgüte und damit auf Trajektorien-Berechnung ermittelt. Dabei wurden von einem Einflussfaktor meist nur zwei verschiedene Zustände betrachtet, um den betriebenen Aufwand für die Versuchsreihe möglichst gering zu halten. Die Brennweiten (fx entspricht horizontaler Brennweite, fy entspricht vertikaler Brennweite) und der Hauptpunkt (cx horizontale Koordinate, cy vertikale Koordinate) für die drei verwendeten Sensoren sind in Tab. 5–9 eingetragen und wurden für die gesamte Hauptversuchsreihe verwendet. Sie wurden bereits bei vorhergehenden Versuchen zur Kamerakalibrierung ermittelt.

Tab. 5–9: Intrinsische Kameraparameter verwendeter Sensoren

Parameter Kinect v2 ZED Argos3D

fx [px] 366.2 338.6 706.373

fy [px] 366.2 338.6 703.441

cx [px] 259.7 342.6 143.892

cy [px] 202.2 176.3 184.708

Jeder Versuch wurde identisch bei ZED und Kinect v2 unter gleichen Rahmenbedingungen durchgeführt. Als Referenz diente meist Versuch Nr. 1 für die Kinect v2 und Versuch Nr. 2 für die ZED (siehe Tab. 5–11), da dieser Versuchsaufbau, beruhend auf Erkenntnissen der Vorversuchsreihe, die besten Ergebnisse erwarten lässt.


Seite 59

Des Weiteren musste die Bittiefe der aufgenommenen Datensätze dem Format des SF entsprechen. Verwendete Bittiefe, Bildwiederholrate und Auflösung für jeden Sensor ist in Tab. 5–10 dokumentiert. Dabei bezieht sich die Auflösung auf das Farbbild und das Tiefenbild.

Tab. 5–10: Weitere konstante Kameraparameter

Kameraparameter Kinect v2 ZED Argos3D

Auflösung [px] 512 x 424 672 x 376 352 x 288

Farbbildbittiefe [bit] 24 24 24

Tiefenbildbittiefe [bit] 16 16 16

Bildwiederholrate [fps] 15 30 7.5

Bei der Argos3D stellte es sich als problematisch, heraus ein verwertbares Tiefenbild mit genügend Tiefeninformationen zu erhalten. Dies lag wahrscheinlich an der Distanz, die nötig war, um den gesamten Grundkörper abzubilden und an den mehrschichtigen Solarzellen, welche nur wenig Infrarotlicht reflektieren. Daher musste die Integrationszeit (Belichtungszeit) der Sensoren erhöht werden, was die maximale Bildwiederholrate auf 7.5 fps verringerte.

Die Hauptversuchsreihe wurde stets mit zwei Personen durchgeführt und erstreckte sich insgesamt über zehn Tage.

In Tab. 5–11 ist die Versuchsreihe dokumentiert. Bei der Lage des Targets kann zwischen „parallel“ oder „gekippt“ unterschieden werden. Parallel bedeutet, dass die Kanten des Targets parallel zur XY-Ebene des Kamera-KS ausgerichtet sind. Gekippt beschreibt eine um etwa 17.52 ° geneigte Lage des Targets bezogen auf die XZ-Ebene des Kamera-KS. Des Weiteren beschreibt ein frontaler Lichteinfall eine Lichtquelle hinter der Kamera und ein seitlicher Lichteinfall eine Lichtquelle zur Linken des Targets aus der Sicht der Kamera. Neben dem Sonnensimulator steht noch ein generisches Laborlicht zur Verfügung. Die Skizze Abb. 5–28 zeigt den Aufbau des Labors für seitlichen und frontalen Lichteinfall, sowie die Position des Laborlichts. Der Albedosimulator ist noch nicht berücksichtigt.


Seite 60

Abb. 5–28: Draufsicht-Skizze des RACOON-Labs.

Des Weiteren wird bei allen angegebenen Distanzwerten keine Skalierung berücksichtigt.


Seite 61

Tab. 5–11: Aufbau der Hauptversuchsreihe an RACOON und EPOS


Seite 62

Lage und Position von Servicer und Target im RACOON-Lab werden bei der Ansteuerung über eine LabVIEW VI momentan in Schritten angegeben. Mit Hilfe des OptiTrack-Systems kann diese Schrittzahl in Meter umgerechnet werden. Um die Lage und Position für die Hauptversuchsreihe nachstellen zu können, wird in Tab. 5–12 die Schrittzahl jeder Achse für die Konfiguration der Versuche Nr. 1, Nr. 3, Nr. 4, Nr. 10 und Nr. 15 angegeben. Mit diesen fünf Konfigurationen können sämtliche Versuche nachgestellt werden. Die Schrittzahl von Achse 10 konnte aus Gründen, die in 5.4.1 erläutert wurden, nicht für jeden Versuch exakt festgehalten werden. Sie befand sich jedoch stets zwischen 20000 und 60000 Schritten, was einer Position entspricht, bei dem die seitliche Ansicht des Mockups nicht zum Sensor zeigt. Bei sämtlichen Konfigurationen entsprach das Zentrum des Mockups dem Kamerazentrum. Die Umdrehungsgeschwindigkeit von 1 °/s entspricht 485 Schritten/s auf Achse 10.

Tab. 5–12: Konfiguration jeder Achse (A) von Servicer (Se),Target (T) und Sonnensimulator (S) bei Versuch Nr. 1 (V1), Nr. 3 (V3), Nr. 4 (V4) und Nr. 10 (V10)

A Bezeichnung V1

Schritte auf A V10 Schritte

auf A V15 Schritte

auf A V3

Schritte auf A V4

Schritte auf A

0 Se X 186000 184500 186000 58000 59000

1 Se Y 6800 31900 6800 6800 31900

2 Se rot. Z 0 0 0 0 0

3 Se Z -130000 -135500 -130000 -130000 -135500

4 Se rot. Y 0 0 0 0 0

5 Se rot. X 0 0 0 0 0

6 T C-rot. Z 0 0 0 0 0

7 T C-rot. Y 0 0 0 0 0

8 T rot. X -6000 7000 -6000 -6000 -6000

9 T rot. Y 0 5000 0 0 0

10 T rot. Z 20000-60000 20000-60000 20000-60000 20000-60000 20000-60000

11 S trans 0 0 -850000 0 0

12 S rot 0 0 2800 0 0

Bei allen Versuchen die im RACOON-Lab durchgeführt wurden, wurde der Boxfilter angewendet. Führte die Anwendung zu einer Verbesserung der Metrik Parameter, so wurde die Trajektorie mit angewandtem Boxfilter zur Ergebnisauswertung verwendet. Die Abb. 5–29 zeigt den Drift eines Versuchs ohne Anwendung des Boxfilters auf der linken Seite und mit Anwendung des Boxfilters auf der rechten Seite. In diesem Fall ist eine deutliche Verbesserung des Drifts zu erkennen.


Seite 63

Abb. 5–29: Drift von Versuch Nr. 9 ohne (links) und mit (rechts) Boxfilter.

Dabei ist zu beachten, dass beim Boxfilter nach eigenem Empfinden versucht wurde, einen Großteil störender Strukturen zu entfernen. Daher, ist der verwendete Boxfilter nicht immer der ideale Boxfilter für die verwendete Konfiguration. Außerdem führte die Anwendung eines Boxfilters nicht bei jedem Versuch einem besseren Ergebnis. Bei welchen Versuchen ein Boxfilter verwendet wurde und welche Dimensionen er besitzt, ist in Tab. 5–13 angegeben. Zum Verständnis der Achsen des Boxfilters, sei auf Abb. 5–3 verwiesen.

Tab. 5–13: Verwendeter Boxfilter für Versuche

Nr. u (von/bis) [px] v (von/bis) [px] z (von/bis) [m]

1 80 / 460 90 / 310 0 / 2.5

2 100 / 550 50 / 260 0 / 2.5

3 100 / 400 126 / 266 0 / 4

4 202 / 464 60 / 267 0 / 10

5 80 / 460 90 / 310 0 / 2.5

6 100 / 550 50 / 260 0 / 2.5

7 100 / 400 126 / 266 0 / 4

8 226 / 441 100 / 230 0 / 10

9 76 / 463 64 / 350 0 / 2.5

10 nicht verwendet nicht verwendet nicht verwendet

11 80 / 460 90 / 310 0 / 2.5

12 100 / 550 50 / 260 0 / 2.5

13 76 / 463 64 / 350 0 / 2.5

14 146 / 527 41 / 286 0 / 2.5

15 80 / 460 90 / 310 0 / 2.5

16 145 / 542 48 / 249 0 / 5

17 76 / 463 64 / 350 0 / 2.5

18 146 / 527 41 / 286 0 / 2.5

19 nicht verwendet nicht verwendet nicht verwendet


Seite 64

Mit Hilfe dieser Informationen zum Versuchsaufbau und durch die Überprüfung der Abstände mit dem OptiTrack-System, sollte die Reproduzierbarkeit jedes Versuchs an den beiden Anlagen gegeben sein. Für manche Versuche, welche rein auf die Position und Lage bezogen den gleichen Versuchsaufbau besitzen, musste dennoch ein anderer Boxfilter aufgrund von Umgebungsfaktoren gewählt werden. In Versuch Nr. 16 war beispielsweise die Struktur des Sonnensimulators zu sehen, wenn man den in Versuch Nr. 2 verwendeten Boxfilter anwendete. Da dies zu keinem verwertbaren Ergebnis führte, musste der Boxfilter hier angepasst werden.

Alle Versuche konnten erfolgreich durchgeführt werden und die Ergebnisse quantifiziert werden. Damit ist die Metrik an beiden Anlagen und mit verschiedenen Sensoren erfolgreich validiert. Voraussetzung ist entweder eine Kompatibilität der Datensätze mit dem SF oder eine Trajektorie mit Datenpunkten Pi ϵ ℝn×3 und einem zugehörigen Zeitstempel Ti. Mit diesen Informationen ist bereits eine erste quantitative Bewertung der Trajektorie ohne Referenz möglich.

Nach dem das RACOON-Lab und EPOS vorgestellt und der Versuchsaufbau beschrieben wurde, kann nun die Auswirkung der verschiedenen Einflussfaktoren, welche mit den Parametern der Metrik quantifiziert wurden, auf die Rekonstruktionsgüte betrachtet werden.

Versuchsauswertung

Seite 65

6 Versuchsauswertung

In diesem Kapitel werden die Ergebnisse der insgesamt 19 Versuche der Hauptversuchsreihe präsentiert. Dabei wird die Auswirkung auf die Rekonstruktionsqualität, quantifiziert durch die Parameter der Metrik, von jedem Einflussfaktor (siehe Tab. 3–1) einzeln betrachtet. Des Weiteren werden die Sensoren getrennt voneinander betrachtet.

6.1 Ergebnisse der Hauptversuchsreihe

Bevor jeder einzelne Einflussfaktor im Detail behandelt wird ist in Tab. 6–1 eine Übersicht über die Ergebnisse der Hauptversuchsreihe gegeben. Bei den gelb markierten Feldern verläuft die Trajektorie nach einigen Zeitschritten in die entgegengesetzte Richtung wie anfangs durch das Kriterium in 4.4.5 angenommen. Dieser Richtungswechsel, der in geringerem Ausmaß bei mehreren Versuchen auftritt, tritt bei gelb markierten Versuchen mehrmals auf. Dadurch entsteht ein hoher δi,max Wert und es besteht eine hohe Abweichung zur Kreisform. Gründe für diese Erscheinung werden in 6.2 diskutiert. Rot geschriebene Ziffern entsprechen den absolut höchsten Werten und grüne Ziffern den absolut kleinsten Werten für die entsprechenden Parameter.

Tab. 6–1: Parameter der der Metrik für jeden Versuch der Hauptversuchsreihe auf 3 Nachkommastellen gerundet.

Nr. CF [m] rF [m] ε [°] R [m] δi,max [°]

1 0.318 -0.113 10.432 0.113 98.9

2 1.579 0.495 56.278 0.325 210.626

3 0.852 0.356 16.481 0.370 107.532

4 0.5028 -0.018 39.482 0.959 232.422

5 0.469 0.179 10.941 0.058 63.074

6 0.226 -0.013 13.42 0.151 30.235

7 0.544 0.221 6.53 0.13 74.853

8 2.766 0.89 40.096 0.83 91.162

9 0.549 0.194 5.46 0.084 49.447

10 1.007 0.16 60.63 0.289 70.905

11 0.294 0.146 15.148 0.141 79.5

12 0.917 0.09 54.837 0.226 55.596

13 0.688 0.196 9.456 0.198 49.786

14 0.833 0.129 17.823 0.175 67.296

15 0.499 0.175 12.287 0.118 54.545

16 0.187 0.092 81.025 0.304 48.882

17 0.886 0.27 15.192 0.144 19.827

18 0.488 -0.028 4.888 0.051 36.942

19 - 1.168 22.163 0.45 34.975

Versuchsauswertung

Seite 66

6.1.1 Distanz zum Target

Für den Einflussfaktor „Distanz zum Target“ wird der Abstand vom Sensormittelpunkt zum Mittelpunkt des Targets betrachtet. Die Annahme bestand darin, dass bei Vergrößerung der Abstände eine Verschlechterung der Parameter der Metrik zur Folge hat. Im Fokus für diesen Einflussfaktor stehen Versuche Nr. 3,4,7 und 8.

6.1.1.1 Kinect v2 Versuchsergebnisse

Für die Kinect v2 ist eine deutliche Verschlechterung sämtlicher Parameter zwischen Versuch Nr. 1 und Versuch Nr. 3 sowie zwischen Versuch Nr. 5 und Nr. 7 zu erkennen. Lediglich die Elevation ε verbessert sich im letzteren Fall um näherungsweise 5 °. Damit entsprechen die Ergebnisse der Vermutung.

6.1.1.2 ZED Versuchsergebnisse

Versuch Nr. 4 zeigt deutlich, dass die geschätzte Trajektorie der ZED für eine Distanz von 3.5 m unbrauchbar in Bezug auf die 3D-Rekonstruktionsgüte ist. Ein höhere Umdrehungsgeschwindigkeit in Nr. 8 verbessert das Ergebnis für δi,max und R, platziert den geschätzten Mittelpunkt jedoch weit entfernt vom Referenzmittelpunkt. Dadurch wird die Trajektorie ebenfalls unverwertbar für weitere Verfahren. Abb. 6–1 zeigt die Trajektorien von Nr. 4 und Nr. 8.

Abb. 6–1: Trajektorie und Bestfit-Kreis von Versuch Nr. 4 (links) und Versuch Nr. 8 (rechts).

6.1.2 Winkelgeschwindigkeit des Targets

Die Winkelgeschwindigkeit des Targets wurde in den drei Stufen, 1 °/s, 2 °/s und 4 °/s, betrachtet. Die intuitive Annahme war, dass eine geringere Umdrehungsgeschwindigkeit eine höhere Informationsdichte gewährt und damit ein besseres Ergebnis erzielt werden kann. Durch die Erkenntnisse der Vorversuchsreihe 5.4.1 wurde somit entschieden, die minimale Rotationsgeschwindigkeit auf 1 °/s festzulegen. Für diesen Einflussfaktor werden die Versuche Nr. 5-8, 17 und 18 betrachtet.

Versuchsauswertung

Seite 67


Für die Kinect v2 führte die Erhöhung der Umdrehungsgeschwindigkeit vor allem zu einer Verbesserung von δi,max. Dabei verbesserte δi,max sich bei hohen Umdrehungsgeschwindigkeiten von 4 °/s in Versuch Nr. 17 sogar bis zu dem besten gemessenen Wert. Insgesamt führt die Erhöhung der Umdrehungsgeschwindigkeit, eher zu einer Verbesserung als zu einer prognostizierten Verschlechterung der Qualität der geschätzten Trajektorie.

Abb. 6–2: Geschätzte Trajektorie und Bestfit-Kreis (links) und Drift (rechts) von Versuch Nr. 17.


Die Versuche Nr. 6 und Nr. 18 stellten sich als zwei der fehlerfreisten Versuche der gesamten Versuchsreihe heraus. Wird für Versuch Nr. 6 der zweite Versuch und für Versuch Nr. 18 der vierzehnte Versuch als Referenz betrachtet, so kann eine erhebliche Verbesserung in allen Bereichen erkannt werden. Daraus folgt, dass eine Erhöhung der Umdrehungsgeschwindigkeit bei der ZED zu einer starken Verbesserung der Qualität der geschätzten Trajektorie führt. Ein Vergleich des Drifts und der Residuen des Versuchs Nr. 14 und Nr. 18 verdeutlicht dies:

Versuchsauswertung

Seite 68

Abb. 6–3: Oben links: Residuen von Versuch Nr. 14. Oben rechts: Drift von Nr. 14. Unten links: Residuen von Versuch Nr. 18. Unten rechts: Residuen von Versuch Nr. 18.

6.1.3 Art der Lichtquelle

Im RACOON-Lab standen zur Zeit der Versuchsreihen zwei verschiedene Lichtquellen zur Verfügung. Eine generische Leuchtstoffröhre und der in 5.1.4 vorgestellte Sonnensimulator. Es wurden Versuche In paralleler und gekippter Lage des Targets durchgeführt um den Einflussfaktor „Art der Lichtquelle“ zu untersuchen. Hierbei können die Versuche Nr. 1,2,9,10 mit den Versuchen Nr. 11,12,13,14 verglichen werden.


Beim Faktor „Art der Lichtquelle“ ist für die Kinect v2 auffällig, dass das Licht des Sonnensimulators in gekippter und paralleler Lage zu einer Verschlechterung von R führt. Die These ist, dass der Sonnensimulator mit stärkerer Bestrahlungsstärke im Infrarot-Bereich (siehe Abb. 5–11) als die Leuchtstoffröhre den Infrarot-Sensor der Kinect v2 beeinflusst. Dadurch könnte eine größere Ungenauigkeit der Tiefenwerte im Tiefenbild entsteht. Dies könnte wiederum zu einem „unruhigeren“ Verlauf von dmin führen, was zu einem höheren R führt. Beim Vergleich von Versuch Nr. 9 und Nr. 13, in Abb. 6–4, wird dieser Sachverhalt am deutlichsten.

Abb. 6–4: Verlauf von dmin für Versuch Nr. 9 links und Versuch Nr. 13 rechts.

Versuchsauswertung

Seite 69

Insgesamt führt die Anwendung des Sonnensimulators, entgegen der Erwartung, zu keiner eindeutigen Verschlechterung der Qualität. Das gilt für alle Parameter.


Da die Tiefenerkennung der ZED nicht auf einem Infrarotsensor wie bei der Kinect v2 beruht, wurde sowohl im gekippten als auch im parallelen Zustand kein großer Unterschied in der Qualität der geschätzten Trajektorie erwartet. Diese Vermutung wurde durch die Versuche bestätigt. Darüber hinaus konnten sogar Verbesserungen in allen fünf Parametern festgestellt werden.

6.1.4 Lichteinfallwinkel und Lage des Targets

Die beiden Einflussfaktoren Lichteinfallwinkel und Lage des Targets wurden zusammengefasst, da eine veränderte Lage letztendlich ebenfalls den Lichteinfallwinkel auf die Oberfläche des Targets ändert. Hierbei wurde angenommen, dass die gekippte Lage des Targets die Auswirkung der stark reflektierend silbrigen Folie auf den Driftwinkel reduziert.


Betrachtet man den maximalen Driftwinkel δi,max, ist der aufgestellten Hypothese folgend, eine starke Verbesserung im Drift von Versuch Nr. 1 zu Versuch Nr. 9 und von Versuch Nr. 11 zu Versuch Nr. 13 zu erkennen (siehe Abb. 6–5). Eine mögliche Erklärung hierfür wird in 6.2 gegeben. Aus der Änderung des Lichteinfallwinkels des Sonnensimulators ist jedoch keine Tendenz zu deuten.

Abb. 6–5: Drift von Versuch Nr. 1 links und Drift von Versuch Nr. 9 rechts.


Für die ZED ist ebenfalls von Versuch Nr. 2 auf Versuch Nr. 10 eine deutliche Verbesserung von δi,max durch die Neigung des Targets zu erkennen. Darüber hinaus konnten die beschriebenen Richtungswechsel in ihrer Ausprägung stark reduziert werden.

Versuchsauswertung

Seite 70

6.1.5 Versuch an der EPOS-Anlage

Für den Versuch an der EPOS-Anlage wurden die PMD Datensätze, welche als CSV-Datei vorhanden waren, in das PNG-Format formatiert. Damit konnten sie im SF verwendet werden. Die Ergebnisse des Versuchs zeigen, dass sie sich mit den Ergebnissen des RACOON-Labs vergleichen lassen. Dies war vorerst das einzige Ziel der Versuche an der EPOS-Anlage. Für einen quantitativen Vergleich der Sensoren müssen selbstredend die Rahmenbedingungen, wie Distanz und Lichtverhältnisse, besser aneinander angepasst werden.

Des Weiteren wurden nur für Versuch Nr. 19 die Standardeinstellungen der beiden Trackingalgorithmus-Filter verändert. Mit einem Downsampling-Wert von 1 anstatt standardmäßig 2, und einem ctf-Filter-Wert von 7 anstatt standardmäßig 4 konnte somit das beste Ergebnis erzeugt werden.

Außerdem fällt Versuch Nr. 19 durch einen besonders hohen rF Wert auf.

6.2 Interpretationsansatz und Fazit

In diesem Abschnitt wird eine mögliche Erklärung für die relativ hohen δi,max Werte bei manchen Versuchen erläutert und die wichtigsten Erkenntnisse der Hauptversuchsreihe in vier Kernaussagen zusammengefasst.

Wie schon in der Vorversuchsreihe festgestellt, führt die aluminiumbedampfte Seite des Targets zu einem schnellen Anstieg des Driftwinkels. Dieser Effekt ist besonders anschaulich in Versuch Nr. 5 dargestellt, tritt aber in unterschiedlicher Ausprägung in allen Versuchen auf. Da das Mockup zwei dieser aluminiumbedampften Seiten besitzt ist dieser Effekt während einer kompletten Umdrehung genau zweimal zu beobachten (siehe Abb. 6–6 links). Daher ist der Verlauf des Drifts an diesen beiden Stellen am steilsten und ΔD erreicht den zweit höchsten Wert nach 294 und den höchsten Wert nach 1581 Bildern. Dabei ist ΔD:

𝛥𝐷𝑖 = 𝐷𝑖+1 − 𝐷𝑖 mit 0 ≥ i ≤ n − 1 ( 6–1 )

Der absolute maximale ΔD Wert ergibt sich zu:

𝛥𝐷𝑚𝑎𝑥 = max(|𝛥𝐷|) ( 6–2 )

Damit ergibt sich ΔDmax,Versuch5=0.344 °/frame. Um den Effekt deutlicher zu zeigen wird der Anstieg des Driftwinkels pro 100 Bilder (ΔD100) in Abb. 6–6 rechts dargestellt. Der höchste Wert für den ΔD100-Verlauf wird nach 301 Bildern erreicht und entspricht der Differenz von δ301 und δ201. Der zweit höchste Wert für den ΔD100-Verlauf wird nach 1601 Bildern erreicht und entspricht der Differenz von δ1601

und δ1501.

Versuchsauswertung

Seite 71

Abb. 6–6: Links ist Verlauf des Driftwinkels und rechts Verlauf von ΔD für Versuch Nr. 5 abgebildet.

Der Grund aus dem es während den Bildern mit seitlicher Ansicht zur Verzögerung bzw. einem Richtungswechsel im Verlauf der Trajektorie kommt ist, dass sich die Oberfläche der silbrigen Folie wie ein Spiegel verhält. So entsteht ein Spiegelbild vorbeiziehender Strukturen. Dieses Spiegelbild wird sowohl von der optischen Kamera der ZED, als auch von der IR Kamera der Kinect v2 wahrgenommen. Da sich das wahrgenommene Spiegelbild in die entgegengesetzte Richtung zum Rest der Mockup-Struktur bewegt, ist eine eindeutige Bewegungsrichtung nicht mehr zu jedem Zeitpunkt durch den DIFODO Algorithmus zu erschließen und es kommt zur besagten Verzögerung. Die Abb. 2–1 zeigt um ΔDmax,Versuch5 gewählte Tiefenbilder des Versuchs Nr. 5. Das Hauptaugenmerk sollte auf den dunklen Strukturen liegen, die sich zunächst im linken Eck des Mockups befinden und sich im Verlauf der Bilder in das rechte Eck bewegen.

Abb. 6–7: Von links nach rechts Tiefenbilder 1513,1555,1615,1637 der seitlichen Ansicht des Versuchs Nr. 5.

In Extremfällen, wie Versuch Nr. 2, verläuft die errechnete Trajektorie ab den Bildern mit seitlicher Ansicht in die umgekehrte Richtung. Dies führt zu einem extrem hohen δi,max Wert.

Wird das Target wie in Versuch Nr. 9 gekippt, so verringert sich die für den Sensor sichtbare aluminiumbedampfte Fläche. Dies führt zu einem flacheren Verlauf des Drifts und somit einem kleineren, Maximalwert von ΔDmax,Versuch9=0.223 °/frame als in Versuch Nr. 5. Idealerweise müsste der Vergleich jedoch mit einem Versuch in gekippter Lage und einer Umdrehungsgeschwindigkeit 2 °/s durchgeführt werden, um die Schlussfolgerung zu bestärken.

Versuchsauswertung

Seite 72

Abb. 6–8: Links ist der Verlauf des Driftwinkels und rechts der Verlauf von ΔD100 für Versuch Nr. 9 abgebildet.

Zu beachten ist jedoch, dass der Trackingalgorithmus bei gekippter Lage des Targets mehr Informationen bezüglich der Form des betrachteten Objekts erhält und dies ebenfalls zu einer Minderung des Drifts führen könnte.

Um die Ergebnisse der Hauptversuchsreihe zusammenzufassen, werden nachfolgend vier Kernaussagen formuliert:

Tab. 6–2: Kernaussagen der Hauptversuchsreihe

Nr. Aussage

1 Umdrehungsgeschwindigkeiten >1 °/s führen bei der ZED zu einer erheblichen Verbesserung der Rekonstruktionsqualität. Eine obere Grenze für die Umdrehungsgeschwindigkeit muss noch erprobt werden.

2 Vergrößerung des Abstands zum Mittelpunkt der Targets führt zu einer starken Verschlechterung der Metrik Parameter für beide Sensoren.

3 Reflektionen auf der seitlichen Target-Oberfläche führen zu Verzögerungen diese erhöhen den Drift stark und verschlechtern damit Rekonstruktionsgüte. Damit ist der Einfallwinkel des Lichts von größerer Bedeutung als die Art der Lichtquelle sein.

4 Sonnensimulator-Licht hat einen messbaren Einfluss auf den IR-Sensor der Kinect v2 und verschlechtert den Parameter R beträchtlich im Vergleich zum Laborlicht.

Zusammenfassend lässt sich behaupten, dass die Metrik eine quantitative Bewertung der Qualität der geschätzten Trajektorie erlaubt. Dabei bringt die Modularisierung in die fünf Metrik-Parameter die Möglichkeit, den Positionsfehler des ATD-Verfahrens in seine rotatorische und translatorische Komponente zu zerlegen und diese isoliert zu betrachten. Mit den Parametern R und δi,max ist somit, selbst ohne Referenztrajektorie, eine Aussage über die Qualität der Trajektorie möglich. Außerdem konnten die Anforderungen aus Tab. 4–1 erfüllt werden.

Versuchsauswertung

Seite 73

Tab. 6–3: Übersicht über Erfüllung der Anforderungen an die Metrik

Nr. Kommentar Status

1 Die Parameter R und δi,max sind unabhängig von einer Referenztrajektorie.

erfüllt

2 Die Metrik greift nur auf Informationen zurück, die durch das OptiTrack-System und das SF bereitgestellt werden.

erfüllt

3 Die Metrik wurde in MATLAB implementiert. erfüllt

4 Die Metrik ist für den Einsatz unter Windows portierbar. erfüllt

5 Die Metrik besteht aus fünf verschiedenen Bewertungsparametern.

erfüllt

6 Die Metrik wurde am RACOON-Lab und an der EPOS-Anlage erfolgreich validiert.

erfüllt

Da diese jedoch sehr allgemein formuliert wurden gilt es im nächsten Kapitel kritisch zu hinterfragen, in welchen Szenarien die entwickelte Metrik eine alternative für herkömmliche Bewertungsverfahren darstellen könnte.

Diskussion

Seite 74

7 Diskussion

In diesem Abschnitt soll diskutiert werden, ob die entwickelte Metrik sich für den Einsatz als Analysetool für das SF des RACOON-Labs eignet. Außerdem wird kritisch hinterfragt, ob die Ergebnisse der Hauptversuchsreihe eine gültige Aussage bezüglich der Auswirkung ausgewählter Einflussfaktoren auf die Rekonstruktionsgüte erlauben.

7.1 Die Metrik als Analysetool

Der in die Metrik eingebaute Circlefit-Algorithmus ermöglicht eine Bewertung der geschätzten Trajektorie komplett ohne Referenztrajektorie, ist jedoch gleichzeitig, in Bezug auf den Einsatzbereich, der limitierende Faktor der Metrik. Die komplette Metrik baut auf der Annahme auf, dass es sich bei den Versuchen um Kreisförmige Inspektionsszenarien handelt. Diese Annahme ist vertretbar, da eine Kreisbahn um das zu betrachtende Objekt eine einfache Möglichkeit darstellt um einen Großteil der Oberfläche zu betrachten. Dennoch ist die Anwendung der Metrik für Szenarien anderer Form komplett unbrauchbar. Eine linienartige Bewegung, wie bei einem Anflug- oder Bergungsmanöver, ist beispielsweise nicht mit der entwickelten Metrik zu bewerten. Das ATD-Verfahren liefert eine valide Aussage bezüglich der Qualität der geschätzten Trajektorie, unabhängig von der Form der Referenztrajektorie.

Es stellt sich jedoch die Frage, wie groß die Aussagekraft einer solchen allgemein gültigen Metrik, wie dem ATD-Verfahren, ist. Mit Hilfe des modularen Aufbaus der entwickelten Metrik, konnte der Drift isoliert vom translatorischen Fehler betrachtet werden und somit der Effekt der stark reflektierenden Seite des Mockups verständlich dargestellt werden. Diese Betrachtung wäre möglicherweise nur bedingt mit dem ATD-Verfahren machbar.

Jedoch bietet die Metrik keinerlei Möglichkeit die Lage des Sensors im Raum zu überprüfen. Dies war im Rahmen des Szenarios nicht nötig, da eine Änderung der Lage der Sensoren nicht vorgesehen war. Sollte eine solche Änderung jedoch für weitere Versuche vorgesehen sein, müsste eine umfangreiche Überarbeitung der Metrik erfolgen.

Weiterhin gilt zu erwähnen, dass mit Referenzparametern, wie Zentrum CG, Radius rG, Startpunkt P0 und der Referenzenebene, der Referenzkreis erstellt werden kann. Dieser könnte theoretisch als Referenztrajektorie fungieren. Damit könnte ein ATD-Verfahren angewendet werden. Diese Möglichkeit, verfügbar durch das OptiTrack-System, bot sich jedoch erst zum Ende der Entwicklungsphase und wurde daher nicht implementiert.

Kann die Richtung der Trajektorie durch die Kriterien in 4.4.5 nicht eindeutig bestimmt werden, beispielsweise bei mehreren Richtungswechseln der Trajektorie, so kommt es zu einem fehlerhaften Driftverlauf. Die verbliebenen Parameter können zwar dennoch betrachtet werden, das ATD-Verfahren bleibt jedoch komplett unbeeinflusst von derartigen Richtungswechseln. Die Metrik erlaubt jedoch die Identifikation solcher Trajektorien-Verläufe mit Richtungswechsel, da δi,max Werte erreicht, welche weit über den δi,max Werten derjenigen Verläufe ohne Richtungswechsel, liegt.

Diskussion

Seite 75

Zusammengefasst erfüllte die Metrik sämtliche der gestellten Anforderungen und ermöglichte die Formulierung von vier Erkenntnissen (siehe Tab. 6–2). Außerdem erlaubt sie eine quantitative Bewertung der Qualität der geschätzten Trajektorie. Sie ist jedoch durch ihre relativ hohe Komplexität sehr in ihrer Anwendung auf das in 3.1 beschriebene Szenario beschränkt. Nach den erweiterten Möglichkeiten die sich durch das Optitrack-System bieten, könnte eine Kombination aus dem ATD-Verfahren und der entwickelten Metrik ein raffiniertes Analysetool für das SF bieten.

7.2 Kritische Betrachtung der Versuche

Wie bereits erwähnt wurde, ist die Umdrehungsrichtung und Startposition des Targets bei den Versuchen nur teilweise berücksichtigt. Es stellt sich jedoch die Frage, ob dieser Umstand die Vergleichbarkeit der Versuche untereinander maßgeblich einschränkt und ob es weitere Einflussfaktoren gibt, die ebenfalls unberücksichtigt blieben.

Bezüglich der Startposition ergab sich aus Vorversuchsreihe, dass darauf geachtet werden sollte die Aufnahme nicht auf seitlicher Position zu starten, um eine falsche Schätzung der Umdrehungsrichtung zu vermeiden. Der Umdrehungsrichtung kann kein größerer Einfluss zugesprochen werden. Es verbleiben zwei Einflüsse. Zum einen die Softwareparameter, welche in Tab. 3–1 aufgezählt wurden, und zum anderen der Boxfilter.

Einem Softwareparameter wie der Bildwiederholrate kann unter Umständen die gleiche Bedeutung wie einer höheren Umdrehungsgeschwindigkeit zugesprochen werden. Dabei erhält der Trackingalgorithmus bei einer Umdrehungsgeschwindigkeit von 2 °/s und einer Bildwiederholrate von 30 fps die gleiche Menge an Information pro Umdrehung wie bei einer Umdrehungsgeschwindigkeit von 1 °/s und einer Bildwiederholrate von 15 fps. Für weitere Versuche muss daher die Bildwiederholrate, speziell im Fall der ZED, entweder an die Kinect v2 angepasst werden oder die Umdrehungsgeschwindigkeit skaliert werden. Die weiteren Softwareparameter könnten ebenfalls einen gewissen Einfluss besitzen und müssten für kommende Projekte genauer betrachtet werden.

Der Boxfilter erlaubt eine enorme Verbesserung der Qualität der geschätzten Trajektorie, muss jedoch auf Versuche mit verschiedenen Lagen und Distanzen des Targets zum Sensor angepasst werden. Es wurde stets versucht den optimalen Boxfilter zu finden in dem alle störenden Strukturen entfernt wurden. Dies war jedoch nicht immer möglich. Um Versuchsergebnisse besser untereinander zu vergleichen, müsste stets der exakt gleiche Boxfilter verwendet werden oder ein Algorithmus geschrieben werden, der den Boxfilter bezogen auf die Parameter der Metrik optimiert.

Dennoch konnten aus dem Versuchsaufbau erste Eindrücke über die verschiedenen Einflussfaktoren und die Sensoren gewonnen werden. Der Vergleich zwischen den Sensoren kann als erste grobe Richtlinie für weitere Versuche herangezogen werden. Versuche eines Sensors mit gleichem Boxfilter, können ohne weitere Bedenken miteinander verglichen werden.

Zusammenfassung der Arbeit

Seite 76

8 Zusammenfassung der Arbeit

In dieser Arbeit wurde eine Metrik entwickelt, welche es ermöglicht ohne Referenztrajektorie eine Aussage über die Rekonstruktionsgüte von Trackingalgorithmen zu treffen. Dabei wurde angenommen, dass die Rekonstruktionsgüte maßgeblich von dem Fehler der geschätzten Trajektorie, welche von Trackingalgorithmen errechnet wird abhängt.

Die Metrik wurde in MATLAB implementiert und basiert auf einem Circlefit-Algorithmus dem die Methode der kleinsten Quadrate zu Grunde liegt, um den am besten angepassten Kreis für eine Punktwolke zu bestimmten.

Um die Metrik zu validieren, wurden Versuche am RACOON-Lab und der EPOS-Anlage durchgeführt, welche die Auswirkung von festgelegten Einflussfaktoren auf die Rekonstruktionsgüte quantitativ bewerten.

Die Versuche an der EPOS-Anlage wurden im Rahmen eines zweimonatigen Aufenthalts beim DLR-Standort in Oberpfaffenhofen durchgeführt. Des Weiteren ermöglichte der Aufenthalt, Informationen über Aufbau und Funktionsweise der EPOS-Anlage zu sammeln und letztendlich die beiden HIL-Anlagen miteinander zu vergleichen. Damit konnte eine Wissensgrundlage für zukünftige Austauschprojekte geschaffen werden.

Nach jeweils einer Vorversuchs- und Hauptversuchsreihe am RACOON-Lab und an der EPOS-Anlage konnten mit Hilfe der Metrik vier Kernaussagen (siehe Tab. 6–2) formuliert werden. Dabei weißen die Kernaussagen auf die Effekte und Einflussfaktoren, welche die Rekonstruktionsgüte besonders stark beeinflussen, hin. Da Softwareparameter während dieser Versuchsreihe nicht berücksichtigt wurden, ist ein direkter Vergleich zwischen den drei verwendeten Sensoren noch nicht möglich. Die Ergebnisse können jedoch als erste grobe Richtlinie für weitere Versuche hergenommen werden.

Aufgrund des mathematischen Aufbaus der Metrik ist sie im Gegensatz zum ATD-Verfahren, nur auf ein Inspektionsszenario anzuwenden. Dennoch kann sie als Analysetool für das SF verwendet werden, da sie durch die isolierte Betrachtung verschiedener Fehlerparameter (CF, rF, ε, R, δi,max) eine gezieltere Aussage bezüglich der Rekonstruktionsqualität, als bspw. das ATD-Verfahren, erlaubt.

Mit dieser Metrik sei ein weiterer Schritt auf dem Weg zu einer umfassenden Lösung zur korrekten Lageschätzung und letztendlich 3D-Rekonstruktion eines unbekannten Objekts, im Rahmen der teleoperierten oder autonomen Nahbereichsnavigation, im Orbit getan.

Ausblick

Seite 77

9 Ausblick

Im Rahmen zukünftiger Kooperationen mit dem DLR könnten weitere Studien zur Rekonstruktionsqualität durchgeführt werden, die vorsehen die Sensoren unter gleichen Umgebungsbedingungen zu testen.

Um jedoch einen quantitativen Vergleich zwischen den Sensoren zu ermöglichen, müsste zunächst der Einfluss sämtlicher Softwareparameter auf die Rekonstruktionsqualität ausgewertet werden. Hierfür sind umfangreiche Versuchsreihen nötig.

Mit den Ergebnissen dieser Arbeit konnte festgestellt werden, dass die Bildwiederholrate, als ein entscheidender Softwareparameter, einen starken Einfluss auf die Rekonstruktionsqualität haben kann. Damit wäre es von Vorteil eine optimale Bildwiederholrate für die verschiedenen Sensoren zu finden. Speziell bei der ZED scheint die aktuell verwendete Bildwiederholrate von 30 fps ein hohes Optimierungspotential zu bieten.

Neben den Softwareparametern besitzt auch der Boxfilter ein hohes Verbesserungspotential. Daher könnten zukünftige Projekte versuchen einen Optimierungsalgorithmus, mit Hilfe der Metrik, zu entwickeln. Damit könnte der optimale Boxfilter für jeden Versuchsaufbau ermittelt werden. Des Weiteren könnten mit einer ähnlichen Herangehensweise, die optimalen Werte für andere Parameter des SF, wie beispielsweise die ctf-Level oder das Downsampling bestimmt werden.

Außerdem, könnte in zukünftigen Projekten eine Metrik entwickelt werten, welche den Mappingalgorithmus bewertet. Eine quantitative Bewertung des rekonstruierten Objekts kann beispielsweise über ein CAD-Modell-Fitting erzielt werden.

Die Untersuchung weiterer SLAM-Algorithmen konnte im Rahmen dieser Arbeit zwar nicht behandelt werden, bietet jedoch eine äußerst vielversprechende Möglichkeit die Aussagekraft der Metrik zu erproben. Ein besonders vielversprechender Algorithmus ist hierbei der DVO-SLAM, welcher eine Verbesserung der Rekonstruktionsgüte verspricht.

Literaturverzeichnis

Seite 78

A Literaturverzeichnis

[1] LIOU, J. C. ; JOHNSON, N. L.: Planetary science. Risks in space from orbiting debris, Bd. 311, S. 340–341

[2] FLEISCHNER, A., M. WILDE, AND U. WALTER.: RACOON-A hardware-in-The-loop simulation environment for teleoperated proximity operations. In: Proceedings of the International Symposium on Artificial Intelligence, Robotics, and Automation in Space (I-SAIRAS 2012).

[3] BOGE, Toralf ; WIMMER, Tilman ; MA, Ou ; TZSCHICHHOLZ, Tristan: EPOS - Using Robotics for RvD Simulation of On-Orbit Servicing Missions (AIAA MODELING AND SIMULATION TECHNOLOGIES CONFERENCE). Toronto, Canada, August 2010

[4] WIESE, Tim: Integration einer RGB-D-Kamera mit Visual-SLAM-Algorithmen in eine Simulationsumgebung zur Verbesserung der Nahbereichsnavigation im Orbit, 2015 (LRT-SA 2016/03)

[5] JAIMEZ, Mariano ; GONZALEZ-JIMENEZ, Javier: Fast Visual Odometry for 3-D Range Sensors, Bd. 31, S. 809–822

[6] STEINBRUCKER, Frank ; STURM, Jurgen ; CREMERS, Daniel: Volumetric 3D mapping in real-time on a CPU

[7] STURM, Jrgen ; ENGELHARD, Nikolas ; ENDRES, Felix ; BURGARD, Wolfram ; CREMERS, Daniel: A benchmark for the evaluation of RGB-D SLAM systems

[8] SETTERFIELD, Timothy P. ; MILLER, David ; LEONARD, John J. ; SAENZ-OTERO, Alvar: Smoothing-Based Estimation of an Inspector SatelliteTrajectory Relative to a Passive Object. In: IEEE (2017)

[9] NISTER, D. ; NARODITSKY, O. ; BERGEN, J.: Visual odometry, S. 652–659

[10] HUANG, Albert S. ; BACHRACH, Abraham ; HENRY, Peter ; KRAININ, Michael ; FOX, Dieter ; ROY, Nicholas: Visual Odometry and Mapping for Autonomous Flight Using an RGB-D Camera. In: Proceedings of the International Symposium of Robotics Research.

[11] BESL, Paul J. ; MCKAY, Neil D.: A Method for Registration of 3-D shapes, 14(2). In: IEEE Transactions on Pattern Analysis and Machine Intelligence, S. 239–256

[12] MAIMONE, Mark ; CHENG, Yang ; MATTHIES, Larry: Two years of Visual Odometry on the Mars Exploration Rovers, Bd. 24, S. 169–186

[13] MA, Yi ; KOSECKA JANA ; SOATOO STEFANO ; SASTRY SHANKAR: An Invitation to 3-D VisionFrom Images to Models, 2001

[14] HORN, Berthold K. P.: Closed-form solution of absolute orientation using unit quaternions. In: Journal of the Optical Society of America A 4 (1987), Nr. 4, S. 629

[15] OLSON, Edwin ; KAESS, Michael: Evaluating the Performance of MapOptimization Algorithms. In: RSS Workshop on Good Experimental Methodology in Robotics (2009), Nr. 15


Seite 79

[16] CIADAMIDARO, Antonio: Design and implementation of a sun simulator for a simulation environment for close-range navigation of satellites : B. Sc. thesis, Technical University of Munich RT-BA 2016/07. B. Sc. thesis, Technical University of Munich RT-BA 2016/07 (2016)

[17] KARPFINGER, Christian: Höhere Mathematik in Rezepten : Das lineare Ausgleichsproblem : Springer Spektrum, 2013

[18] OptiTrack. URL http://optitrack.com/ – Überprüfungsdatum 2017-05-12

[19] Fitting a Circle to Cluster of 3D Points. URL https://meshlogic.github.io/posts/jupyter/curve-fitting/fitting-a-circle-to-cluster-of-3d-points/. – Aktualisierungsdatum: 2016 – Überprüfungsdatum 2017-05-02

[20] RANDY BULLOCK: Least-Squares Circle Fit. URL http://www.dtcenter.org/met/users/docs/write_ups/circle_fit.pdf. – Aktualisierungsdatum: 2017-02-12 – Überprüfungsdatum 2017-05-18

[21] BELONGIE, Serge: Rodrigues’ rotation formula (1999)

[22] BARTSCH, Hans-Jochen: Taschenbuch mathematischer Formeln. 21. Aufl. München : Fachbuchverl. Leipzig im Carl-Hanser-Verl., 2007

[23] NOMEN4OMEN: arctan2. URL https://commons.wikimedia.org/wiki/File:Arctangent2%2B.png. – Aktualisierungsdatum: 2017-02-18 – Überprüfungsdatum 2017-05-23

[24] MATLAB: atan2. URL https://de.mathworks.com/help/matlab/ref/atan2.html. – Aktualisierungsdatum: 2017 – Überprüfungsdatum 2017-05-06

[25] TAUBIN, G.: Estimation of planar curves, surfaces, and nonplanar space curves defined by implicit equations with applications to edge and range image segmentation. In: IEEE Transactions on Pattern Analysis and Machine Intelligence 13 (1991), Nr. 11, S. 1115–1138

[26] NIKOLAI CHERNOV: Circle Fit (Taubin method). URL https://de.mathworks.com/matlabcentral/fileexchange/22678-circle-fit--taubin-method-. – Aktualisierungsdatum: 2009-01-13 – Überprüfungsdatum 2017-06-07

[27] MATLAB: knnsearch. URL https://de.mathworks.com/help/stats/knnsearch.html – Überprüfungsdatum 2017-05-08

[28] TUM Lehrstuhl für Raumfahrttechnik, "RACOON Lab". URL https://www.lrt.mw.tum.de/index.php?id=54&L=0. – Aktualisierungsdatum: 2016 – Überprüfungsdatum 2017-04-11

[29] OTTO, Julian.: Development of an Absolute Reference Measurement System inthe Racoon Hardware Lab. Technische Universität München, Lehrstuhl für Raumfahrtrechnik (LRT-MA 2016/08) (2016)

[30] TUM RACOON-Lab,"Anleitungsartikel". URL https://wiki.tum.de/display/racoon/Anleitungsartikel. – Aktualisierungsdatum: 2016-10-07 – Überprüfungsdatum 2017-04-11

[31] DZIURA, Martin ; WIESE, Tim ; HARDER, Jan: 3D Reconstruction in Orbital Proximity Operations. In: IEEE.

[32] HARDER, Jan: RACOON - Infrastructure : Specification Sheet


Seite 80

[33] ZHANG, Zhengyou: Microsoft Kinect Sensor and Its Effect. In: IEEE Multimedia 19 (2012), Nr. 2, S. 4–10

[34] LACHAT, E. ; MACHER, H. ; MITTET, M.-A. ; LANDES, T. ; GRUSSENMEYER, P.: FIRST EXPERIENCES WITH KINECT V2 SENSOR FOR CLOSE RANGE 3D MODELLING. In: ISPRS - International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences XL-5/W4 (2015), S. 93–100

[35] Microsoft, "Pre-order your Kinect for Windows v2 sensor starting today". URL https://blogs.msdn.microsoft.com/kinectforwindows/2014/06/05/pre-order-your-kinect-for-windows-v2-sensor-starting-today/. – Aktualisierungsdatum: Juni 2014 – Überprüfungsdatum 2017-04-11

[36] SEITZ, S. M. ; CURLESS, B. ; DIEBEL, J. ; SCHARSTEIN, D. ; SZELISKI, R.: A Comparison and Evaluation of Multi-View Stereo Reconstruction Algorithms (2016), S. 519–528

[37] Microsoft, "Kinect hardware". URL https://developer.microsoft.com/en-us/windows/kinect/hardware. – Aktualisierungsdatum: 2017 – Überprüfungsdatum 2017-04-11

[38] Stereolabs, "The camera that senses space and motion". URL https://www.stereolabs.com/zed/specs/. – Aktualisierungsdatum: 2017 – Überprüfungsdatum 2017-04-11

[39] HARTLEY, Richard ; ZISSERMAN, Andrew: Multiple view geometry in computer vision. 2. ed. Cambridge : Cambridge Univ. Press, 2003

[40] Standard Solar Constant and Zero Air Mass Solar Spectral Irradiance Tables

[41] REICHENBACH, Nico: Entwicklung und Integration eines Erdalbedosimulators zum Testen von Sensoren für die Nahbereichsnavigation von Satelliten im Erdorbit, 2017, (LRT-SA 2017/02)

[42] Universität Leipzig - LIM. URL http://meteo.physgeo.uni-leipzig.de/de/index.php – Überprüfungsdatum 2017-05-26

[43] BENNINGHOFF, Heike: EPOS 2.0 : EPOS User Manual, 2016

[44] BENNINGHOFF, H. ; REMS, R. ; RISSE, E.-A., MIETNER C.: European Proximity Operations Simulator 2.0 (EPOS) - A Robotic Based Rendezvous and Docking Simulator. In: Journal of Large-Scale Research Facilities (2016)

[45] BLUETECHNIX PRODUCTS: Bluetechnix, "Argos Cameras". URL www.bluetechnix.com/en/products/depthsensing/list/argos/ – Überprüfungsdatum 2017-04-12

[46] BLUETECHNIX PRODUCTS (Hrsg.): Argos3D-P320 Hardware User Manual, 2015

[47] BLUETECHNIX PRODUCTS (Hrsg.): Argos 3D - P320 Quick Start Guide, 2016

[48] BOGE, Toralf ; WIMMER, Tilman ; MA, Ou ; TZSCHICHHOLZ, Tristan: EPOS - Using Robotics for RvD Simulation of On-Orbit Servicing Missions.

[49] KLIONOVSKA KSENIA: Gefährdungsbeurteilung DLR-Argos3D - P320 30 °, 2016

Anhang

Seite 81

B Anhang

B.1 Ergebnisse Hauptversuchsreihe

Im Folgenden ist Trajektorie und der Bestfit-Kreis, die Verläufe von dmin, dminXY, dminZ und der Drift der Versuche 1-19 aufgetragen. Dabei ist die Trajektorie stets links, dmin mittig und der Drift rechts dargestellt.

Versuch Nr. 1:

Versuch Nr. 2:

Versuch Nr. 3:

Versuch Nr. 4:

Anhang

Seite 82

Versuch Nr. 5:

Versuch Nr. 6:

Versuch Nr. 7:

Versuch Nr. 8:

Anhang

Seite 83

Versuch Nr. 9:

Versuch Nr. 10:

Versuch Nr. 11:

Versuch Nr. 12:

Anhang

Seite 84

Versuch Nr. 13:

Versuch Nr. 14:

Versuch Nr. 15:

Versuch Nr. 16:

Anhang

Seite 85

Versuch Nr. 17:

Versuch Nr. 18:

Versuch Nr. 19:

Experimentelle Studie mit RACOON und Epos zur ...mediatum.ub.tum.de/doc/1443240/1443240.pdf · the...

Documents

Transcript of Experimentelle Studie mit RACOON und Epos zur ...mediatum.ub.tum.de/doc/1443240/1443240.pdf · the...