Baukasten "Kollaborative Integrität"

Konzept

Im Graduiertenkolleg i.c.sens werden methodische Grundlagen, sowie Integritäts- und Kollaborationskonzepte für dynamische Sensornetze in Verbindung mit digitalen Karten erarbeitet. Navigationsinformationen stehen hierbei im Fokus. Die Ergebnisse werden in Form eines anwendungsübergreifenden „Baukastens kollaborative Integrität“ verfügbar gemacht, der sich mit geringem Aufwand in konkrete Applikationen integrieren lassen soll, so dass neue Anwendungsfelder und kostensensitive Applikationen erschlossen werden. Neben dem generischen, zunächst rein „methodischen Baukasten“, welcher Integrität und Kollaboration für die Aufgabenstellung der Zustandsschätzung realisiert, werden spätere Kohorten die erarbeiteten Konzepte im Sinne eines anwendungsübergreifenden „Baukastens kollaborative Integrität“ bündeln, der anhand exemplarischer Fragestellungen (z. B. des autonomen Fahrens) verifiziert werden soll.

Eines der wesentlichen Ziele des Graduiertenkollegs ist es, aus den von den Doktoranden entwickelten Algorithmen zur Datenanalyse und/oder Datentransformation lauffähige Softwaremodule abzuleiten, die auch in anderen Anwendungskontexten wiederverwendbar sind. Im Zusammenhang mit der praktischen Umsetzung fallen Fragestellung in den Bereichen des Software Engineerings und der Systemarchitektur an.  Gemeinsames Merkmal dieser Softwaremodule ist die prinzipielle Fähigkeit, Integritätsparameter der Eingabe in Integritätsparameter der Ausgabe zu überführen, also quantifizierte Unsicherheiten/Genauigkeiten, mit denen die Eingabedaten - bspw. Messdaten von physischen Sensoren oder vorgelagerten Prozessen - behaftet sind, durch Methoden wie Fehlerfortpflanzung innerhalb der Algorithmen zu berücksichtigen. Ergebnis dieser Module ist dann nicht allein eine wahrscheinlichste Lösung des implementierten Algorithmus, sondern daneben auch ein Maß für die Sicherheit des Moduls, dass das Ergebnis korrekt ist. Bestehen komplexe Algorithmen aus aufeinanderfolgenden, unabhängigen Teilschritten, werden diese in einzelne, sequenziell ausführbare Module überführt. Dies erlaubt den Einsatz der im Graduiertenkolleg erarbeiteten Methoden im Rahmen von sicherheitskritischen Anwendungen, bei denen Garantien für die Korrektheit von Berechnungen oder eine zuverlässige Quantifizierung des erwarteten Fehlers benötigt werden.

Softwaretechnische Herausforderungen

Kern des Baukastenkonzeptes ist hierbei die Interoperabilität der entwickelten Softwaremodule untereinander: bei Übereinstimmung der entsprechenden Schnittstellen lassen diese sich zu einer Prozesskette verknüpfen, bei der die Integrität aller Verarbeitungsschritte lückenlos sichergestellt ist. Hieraus resultiert die Notwendigkeit einheitlicher Kommunikationskanäle, also entweder programmiersprachen-unabhängiger inter-Prozess-Kommunikation oder einer einheitlichen Programmiersprache oder eines einheitlichen Programmierumgebung bei der Entwicklung der Module. Nebeneffekt dieser praktischen Anforderung ist die Wiederverwendbarkeit von Modulen innerhalb des Graduiertenkollegs: die Doktoranden werden mit fortschreitender Dauer des Graduiertenkollegs auf immer mehr bereits implementierte integre Variante von anwendungsübergreifend verwendbaren Algorithmen zurückgreifen und diese als Komponente in ihren eigenen Analyseverfahren wiederverwenden können.

In Vorbereitung der koordinierten Entwicklung von Softwaremodulen für den Baukasten in Kohorte 1 wurden bereits während der ersten Kohorte Überlegungen zu geeigneten gemeinsamen Entwicklungsumgebungen (Programmiersprachen und -frameworks) angestellt, und erste Prototypen zu einzelnen konkreten Algorithmen entwickelt. Die hierbei gewonnen Erfahrungen sind Ausgangspunkt für die gemeinsamen Spezifikations- und Entwicklungstätigkeiten ab Kohorte 2.

ROS

In diesem Zusammenhang erfolgte früh eine Entscheidung für ROS (Robot Operation System) als gemeinsames Framework für die Baukastenmodule. ROS ist ein Open-Source "Meta-Betriebssystem", das betriebssystem-typische Funktionalitäten nachbildet, u.a. eine eigene Interprozesskommunikations-Schnittstelle anbietet, und dadurch unabhängig von der Hardware und den verwendeten Betriebssystemen die Ausführung von verteilten Prozessen (auf einem Rechner oder innerhalb eines Rechnernetzes) erlaubt. Die Kopplung dieser Prozesse erfolgt hierbei lose über generische, textbasierte Kommunikationskanäle (sog. topics), die über das publish/subscribe-Entwurfsmuster realisiert werden. Durch seine Popularität in der Robotik existieren für ROS zahlreiche frei verfügbare Module, die in der Robotik häufig benötigte Funktionalitäten realisieren. Hierzu gehören auch Treiber für eine Vielzahl der in den Experimenten des GRK eingesetzten Sensoren, die eine direkte Integration von Sensor-Live-Daten und der weiterverarbeitenden Module ermöglichen. Eine in diesem Zusammenhang nützliche Fähigkeit von ROS ist die Erzeugung von chronologischen Aufzeichnungen (sog. ROSBags) der Kommunikation über bestimmte Topics (bspw. Sensordaten), die zu einem späteren Zeitpunkt erneut abgespielt werden können. Hierdurch können Algorithmen zeitversetzt auf realen Daten entwickelt und getestet werden.

Im Zusammenhang mit der Entwicklung der ersten Protoypen in Kohorte 1 wurde bereits untersucht, welcher Mehr-Aufwand bei der Transformation der in den Promotionsvorhaben entwickelten Algorithmen zu lauffähigen ROS-Modulen anfällt. Direkte Entwicklung in einer ROS-Umgebung stellt hier den einfachsten Fall dar. Die meisten anderen von den Doktoranden zur Entwicklung genutzte Sprachen (C++, python, MatLab) unterstützen ROS direkt; hier entfällt Bearbeitungsaufwand auf die Einbindung der entsprechenden ROS-Bibliotheken und die Umleitung der Ein- und Ausgaben über ROS-Topics (ggf. mehrfach bei Zerlegung in unabhängige Module).

Koordinierung der Softwareentwicklung

Ab Kohorte 2 ist die Entwicklung der ROS-Module Bestandteil jedes Promotionsvorhabens. In gemeinsamen Programmier-Workshops (sog. "Hackathons") werden die notwendigen Programmiertätigkeiten koordiniert und synchronisiert. In diesem Zusammenhang werden gemeinsame Schnittstellen und Datentypen (insbesondere zur Kommunikation von Integritätsparametern) identifiziert und formal spezifiziert. Für die Doktoranden geben diese Veranstaltungen Gelegenheit, eigene Probleme und Lösungen mit den anderen Mitgliedern des Graduiertenkollegs zu erörtern.

GNSS-Messungen dienen der Stützung der berechneten Pose; bis zur nächsten GNSS-Messung wird die relative Posen-Änderung akkumuliert, bevor sie durch diese korrigiert wird.

Besonderheit beim Ansatz von Herrn Voges ist hierbei die Verwendung von Intervallmathematik zur Modellierung aller Fehler: hierbei werden begrenzende Intervalle als garantierte Wertebereiche für alle Messungen angenommen; über die Lage der tatsächlichen Messwerte innerhalb der Intervalle ist nichts bekannt. Die Intervalle werden in allen anfallenden Operationen berücksichtigt (SIVIA-Algorithmus = „set inversion via interval analysis“ und sog. Kontraktoren); Ergebnis jedes Rechenschrittes sind wieder Intervalle. Vorteil dieser Methode ist die Garantie, dass die berechnete Fahrzeugpose tatsächlich innerhalb der Intervallgrenzen (die jeweils den größtmöglichen Fehler repräsentieren) liegt, sofern die initialen Annahmen für die maximalen Fehler der Sensorbeobachtungen zutreffen.  

Das zweite Beispiel ist der ROS-Knoten für das "Simulation Framework for Collaborative Navigation" von Nicolas Garcia Fernandez, das Daten aus Fahrzeug-Sensoren (Vehicle-to-vehicle- und vehicle-to-environment-Messungen (V2X)) integriert, um die Genauigkeit der Selbstlokalisierung aller Fahrzeuge durch kollaborativen Informationsaustausch zu maximieren. 

Es wird angenommen, dass das Fahrzeug mit einem GNSS-Empfänger (line-of-sight- und non-line-of-sight-Linien zu den empfangbaren GPS-Satelliten sind orange dargestellt), einer IMU (Messungen nicht dargestellt), einem 2D-Laserscanner (dessen Messgeometrie durch blaue Kreise dargestellt wird) und einem Paar Stereokameras (dargestellt durch die beiden konischen Projektionen; roten und grünen Dreiecke für linke bzw. rechte Kamera) ausgestattet ist. Schließlich werden die Messungen des exterozeptiven Sensors durch Schnittpunkte zwischen Strahlen und Ebenen (magenta "x") berechnet. Wenn sich das Fahrzeug bewegt, kann man sehen, wie sich sowohl die Satellitengeometrie als auch die Messgeometrie des exterozeptiven Sensors erheblich ändern.    

Die unteren Panels zeigen die folgenden Parameter, die aus der Schätzung von Fahrzeug 1 (rote Trajektorie) berechnet wurden:

• die Qualität der Satellitengeometrie unter Verwendung der Werte der Horizontal Dilution of Precision (HDOP), wobei auch einige Perioden mit Signalunterbrechung (z.B. 200s nach dem Start) sichtbar sind.
• Die Abweichungen der geschätzten Position in Bezug auf die nominale Flugbahn werden durch die Cross-Track (blau) und Along-Track (magenta) geschätzt.
• Die Abweichungen des geschätzten Kurses in Bezug auf die Nominalwerte.
• Die Abweichungen der geschätzten Geschwindigkeiten im Norden (rot) und Osten (grün) in Bezug auf die Nominalwerte.