Um den Masterstudiengang Informatik/Wirtschaftsinformatik an der Universität Oldenburg erfolgreich zu absolvieren, muss von den Studierenden eine Projektgruppe belegt werden. Eine Projektgruppe stellt eine Lehrveranstaltung dar, in der Studierende im Laufe eines Jahres ein vollständiges (Software-) Projekt durchführen. Das Hauptziel besteht darin, anhand einer gegebenen Problemstellung den gesamten Entwicklungsprozess von der Problemanalyse bis zur Umsetzung der Softwarelösung zu durchlaufen. Dabei erlernen Studierende nicht nur Methoden und Inhalte ihres Studienfachs, sondern auch berufstypische Arbeitsweisen wie Teamarbeit, Aufgabenverteilung und Übernahme von Verantwortung. Gleichzeitig werden persönliche Fähigkeiten wie die Aufbereitung von Inhalten, zielgerichtetes Argumentieren sowie Präsentations- und Urteilsfähigkeit gefördert.

Projektgruppen werden oft in Kooperation mit Unternehmen oder Forschungsinstituten durchgeführt. Das OFFIS Institut für Informatik hat schon häufig Projektgruppen im Bereich Verkehr zusammen mit der Universität Oldenburg angeboten, welches nun im DLR-SE untergebracht wurde. Das Thema der aktuellen PG orientiert sich an dem Forschungsbereich autonomes Fahren und hier im Speziellen mit der Herausforderung der Umgebungserkennung und Klassifizierung im Straßenverkehr. Auch der Name ACDC spiegelt dieses Ziel wider.

Die Lösung der Entwicklung eines automatisierten Fahrsystems lässt sich durch ein Patter mit SENSE-PLAN-ACT Komponenten (auch unter Perception-Planning-Control (PPC) Pattern bekannt) realisieren. Dabei interagiert ein System, welches SENSE-PLAN-ACT realisiert, mit einer Umgebung. Die Wahrnehmung davon wird durch SENSE realisiert, während der nächste Schritt durch PLAN geplant wird und in ACT umgesetzt wird. Dabei wird wieder mit der Umgebung interagiert, wodurch Veränderungen stattfinden und wieder eine neue Wahrnehmung entsteht. 

ADORe konnte in einer Präsentation vom DLR-SE bereits durch das urbane Braunschweig fahren. Im gezeigten Pattern kann ADORe in den Komponenten PLAN und ACT eingeordnet werden. Die in Braunschweig verwendete SENSE-Komponente kann nicht in einer Simulation eingesetzt werden und ist nicht als Open-Source-Software verfügbar. Wie bereits motiviert, könnte die Verwendung von Simulation zur Entwicklung von autonomen Fahrsystemen kostengünstiger und effizienter umsetzen lassen. Die Entwicklung einer SENSE-Komponente für die Simulation CARLA würde genau dieses Problem lösen.

Es existiert bereits ein Modul, welches ADORe in der Simulation CARLA fahren lassen kann. Diese Schnittstelle wird als Interface adore_if_carla benannt. Dabei gibt es ein Problem: Die Daten welche adore_if_carla verwendet, werden von sogenannten ground truth providern erhoben. Ground truth provider sind keine Sensoren, sondern haben Wissen über Metadaten und den tatsächlichen Daten der CARLA Simulation. Sie können daher Annahmen treffen, welche in der Realität durch Einsatz von Sensoren nicht messbar sind. Somit ist eine realistische Umsetzung mit realistischen Testdaten durch adore_if_carla nicht umsetzbar. Es fehlt in dem Modul adore_if_carla, dass ausschließlich realistische Sensordaten aus der Simulation von CARLA an ADORe übergeben werden. Die Projektgruppe möchte das Problem lösen und daher eine Lösung (SENSE-Komponente) entwickeln, welches realitätsnahe Sensoren verwendet und diese Daten an ADORe weitergibt. Mit einem solchen Modul könnte die Softwarelösung mit realistischen Randbedingungen in der Simulation getestet und validiert werden, was durch die folgende Forschungsfrage zusammengefasst wird:

Wie kann eine softwarebasierte Lösung realisiert und implementiert werden, welche die Perzeption für ADORe vorbereitet, sodass ausschließlich realitätsnahe Sensoren aus CARLA für die Wahrnehmung der Umgebung verwendet?

Die Entwickler von ADORe haben das System in der Realität angewendet und getestet. Somit gibt es schon die Entwicklung einer Wahrnehmung in der Realität. Die Perzeption kann nicht von der Projektgruppe verwendet werden, da sie keinen Zugriff auf diese be- sitzt. So wurden bereits realistische Daten an ADORe übermittelt. Der Unterschied zu dem Projekt ACDC ist, dass die Projektgruppe eine Simulationsumgebung verwendet. Wie bereits motiviert, ergeben sich einige Vorteile durch das Testen von Systemen wie ADORe in Simulationsumgebungen. Durch die Entwicklung einer Lösung, welche mit der Simulation CARLA kompatibel ist, bilden sich neue Möglichkeiten der Weiterentwicklung von verschiedenen Lösungen innerhalb dieser Simulationsumgebung.
Wichtig ist nicht nur die reine Umsetzung des Problems, sondern auch die Dokumentation der Umsetzung. Das bedeutet, dass festgehalten wird, welche Methoden und Technologien verwendet wurden. Es müssen die Sensordaten für ADORe verarbeitet werden, weil ADORe gewisse Informationen benötigt, wie zum Beispiel die Information wo sich weitere Verkehrsteilnehmer befinden. Deshalb muss die Wahrnehmung der Umgebung
so erstellt werden, dass aus den Sensordaten von CARLA diese Informationen erkannt werden. Daraus ergibt sich, dass die Herausforderungen für die Wahrnehmungen das Erkennen von Objekten als auch der Umgebung und die Lokalisierung des eigenen sind.

Wie in der Forschungsfrage definiert, soll eine Lösung entwickelt werden, welche Sensordaten aus CARLA verarbeitet und als Information an ADORe weitergibt. Durch CARLA wird eine Umgebung simuliert und anschließend die Steuerung von ADORe verarbeitet. Dies bedeutet konkret, dass CARLA die Plattform für ein Fahrzeug, mit den simulierten Sensordaten, darstellt. Die Bereitstellung erfolgt durch eine Python Schnittstelle oder kann durch die ROS-Bridge erfolgen. Die ROS-Bridge veröffentlicht die Sensordaten unter verschiedenen ROS-Topics in einem fest definierten Nachrichtentyp. Die zerarbeitende Software-Lösung hat keinen Einfluss auf die Umgebung, da die Steuerung von ADORe bestimmt wird und direkt an die Simulation weiter gegeben wird. Entsprechend können nur Sensordaten und Umgebungen verwendet werden, wie sie durch die Simulation CARLA definiert sind.

Die zu entwickelnde Softwarelösung wird durch die verwendete Simulation CARLA eingegrenzt. So werden ausschließlich Karten und Fahrzeuge aus der CARLA Bibliothek genutzt, durch welche die Sensordaten erfasst werden und somit insgesamt die Softwarelösung evaluiert werden kann. Randszenarien, wie eine Baustelle oder Schlaglöcher in der Straße, werden nicht berücksichtigt, da sie in CARLA nicht existieren. Um die Daten der SENSE-Komponente an ADORe weiterzuleiten, stellt ADORe eine Perzeptions-API bereit. Es werden die erwarteten Daten als ROS1-Nachrichten definiert, welche von der Softwarelösung dieser Projektgruppe an die Perzeptions-API gesendet werden müssen. Es ist durch die API vollständig definiert, wie genau die erwartete Beschreibung der Umgebung auszusehen hat und entsprechende Nachrichten zu versenden sind, sodass eine Steuerung durch die ADORe bestimmt werden kann.

Wie oben bereits beschrieben gibt es bereits eine Schnittstellenlösung adore_if_carla, welche basierend auf ground_truth-Daten die erwarteten Eingaben an ADORe weiterleitet. Die Lösung für die Forschungsfrage differenziert sich dadurch, dass eine Auswahl an Sensoren verwendet wird, welche der Realität entsprechen muss.

Die Forschungsfrage wird beantwortet, indem eine Softwarelösung entwickelt wird, welches die Wahrnehmung der Sensordaten aus CARLA an ADORe weitergibt. Hierfür muss die Umgebung vollständig durch die Softwarelösung erkannt werden. Aus CARLA sollen ausschließlich realitätsnahe Sensoren verwendet werden. Realitätsnah bedeutet, dass die Daten von virtuellen Sensoren erhoben werden, welche auch in der Realität durch Sensoren an einem Fahrzeug erhoben werden könnten. Im Gegensatz zu diesen Sensoren stehen ground truth provider. Diese können zwar in CARLA als Sensor an einem Fahrzeug in der Simulation verwendet werden, jedoch liefern sie ground truth Daten aus der Simulation und bilden keine echten Sensoren ab. Realitätsnahe Sensordaten werden durch die Softwarelösung ACDC verarbeitet, sodass die Daten an die Perzeptions-Application Programming Interface (API) gegeben werden können. Die API erwartet hierbei die Informationen über die globale und lokale Fahrzeugposition. Bei der Verwendung von CARLA als Fahrzeugplattform und Simulation können diese beiden Schnittstellen als Lokalisierung zusammengefasst werden. Des Weiteren wird der aktuelle Zustand der Verkehrssteuerung benötigt, worunter Ampeln als auch Straßenschildern fallen. Ebenfalls werden Informationen über weitere Verkehrsteilnehmer und nicht klassifizierbaren Objekten, welche zum Beispiel die Straße versperren könnten, erwartet.

Zusammengefasst wurde das folgende Ziel, abgeleitet aus der Forschungsfrage, definiert:

Das Ziel ist der Entwurf, die Implementierung und das Testen der softwarebasierten Lösung ACDC, welche die Perzeption für ADORe vorbereitet und ausschließlich realitätsnahe Sensoren aus der Simulation CARLA für die Wahrnehmung der Umgebung verwendet.

Um die Lösung zu realisieren, werden die folgenden Anwendungsfälle realisiert. Zum einen müssen die Sensordaten aus CARLA abgerufen werden und entsprechend zu Informationen aufbereitet werden. Da die Perzeptions-API von ADORe vier Arten von Informationen verlangt, entstehen für diese je ein Anwendungsfall.

Aus den Zielen ergeben sich verschiedene Anwendungsfälle, die die Softwarelösung ACDC bearbeiten muss.

Auf der einen Seite steht CARLA als Simulation. Um die Forschungsfrage zu beantworten, müssen Sensordaten empfangen werden und durch die Lösung weiter verarbeitet werden. ADORe selebr kann keine Sensordaten verwendet, sondern eine eigene Schnittstelle durch ROS1 bereitstellt, auf welcher die Daten veröffentlicht werden müssen. Die Komponenten der Perzeptions-API von ADORe müssen mit den korrekten Daten versorgt werden. Das bedeutet, dass ACDC Informationen über Verkehrsteilnehmer, der Lokalisierung, nicht klassifizierbaren Objekten und der Verkehrssteuerung aus der Simulation, aus den Sensordaten verarbeiten muss, um diese an die Perzeptions-API von ADORe übergeben zu können.