Zur Unterst\"utzung in der Entwicklung des Systems benutzen wir die Tools des Robot Operating System (ROS). ROS ist ein beliebtes Framework im Robotik-Bereich und ist durch das Messaging-System zwischen einzelnen ROS-Modulen auf Verteilbarkeit und Modularit\"at ausgerichtet. Weiterhin sind die Module, die uns Assystem liefert, bereits als ROS-Nodes implementiert. Daher ist es sinnvoll, dass wir selbst ROS benutzen, um so die Kompatibilit\"at mit Assystem zu gew\"ahren. ROS unterst\"utzt die Programmiersprachen Python und C++. Da unser System sehr zeitkritisch ist, haben wir uns entschieden, das gesamte System in C++ zu implementieren.
Anstatt ROS-Nodes zu nutzen, haben wir uns jedoch entschieden auf Nodelets umzusteigen. Diese sind vom Konzept her gleich den ROS-Nodes. ROS-Nodes kommunizieren jedoch \"uber TCP untereinander, was eventuell zu einem h\"oheren Zeitaufwand f\"uhrt. Im Gegensatz dazu, kommunizieren Nodelets untereinander durch shared pointer.
Anstatt ROS-Nodes zu nutzen, haben wir uns jedoch entschieden, auf Nodelets umzusteigen. Diese sind vom Konzept her ähnlich. ROS-Nodes kommunizieren untereinander\"uber TCP, was eventuell zu einem h\"oheren Zeitaufwand f\"uhrt. Im Gegensatz dazu kommunizieren Nodelets untereinander über shared pointer.
Das Lanekeeping wird bereits als ROS-Node von Assystem geliefert. Die Kamera und der Ultraschallsensor erhalten jeweils eigene Nodelets, da sie nur damit besch\"aftigt sein werden, ihre Daten aufzunehmen und an ihr rostopic zu publishen. Das Environment Modul ist ein eigener Nodelet, da es die hochfrequenten Daten der Kamera und des Ultraschallsensors lesen und verarbeiten muss. Das MAVLINK Modul ist ein eigener Nodelet, da dessen Aufgabe das Versenden und Empfangen von Nachrichten \"uber das MAVLINK Protokoll ist.
PlatoonController, CruiseControl, Netzwerk, Logging und Egomotion laufen zusammen in einem Nodelet. Das liegt daran, dass beim Designentwurf noch davon ausgegangen wurde, dass ROS-Nodes benutzt werden. Das Gruppieren mehrerer Module innerhalb des gleichen ROS-Nodes, erhofften wir uns einen Performance-Gewinn, da Daten nicht node-\"ubergreifend \"uber TCP verschickt werden m\"ussen, sondern innerhalb des Nodes durch Getter zur Verf\"ugung stehen. Durch die Verwendung von Nodelets, k\"onnte es jedoch sein, dass es keinen Performance-Unterschied gibt, wenn wir die Module PlatoonController, CruiseControl, Netzwerk, Logging und Egomotion auf einzelne Nodelets verteilen. Aus Zeitmangel wollten wir aber das Design nicht mehr \"andern.
PlatoonController, CruiseControl, Netzwerk, Logging und Egomotion laufen zusammen in einem Nodelet. Das liegt daran, dass beim Designentwurf noch davon ausgegangen wurde, dass ROS-Nodes benutzt werden. Durch das Gruppieren mehrerer Module innerhalb des gleichen ROS-Nodes erhofften wir uns einen Performance-Gewinn, da Daten nicht node-\"ubergreifend \"uber TCP verschickt werden m\"ussen, sondern innerhalb des Nodes durch Getter bereitgestellt werden können. Durch die Verwendung von Nodelets k\"onnte es jedoch sein, dass es im Vergleich zur Alternative - die Module PlatoonController, CruiseControl, Netzwerk, Logging und Egomotion auf einzelne Nodelets zu verteilen - zu keinem Performance-Gewinn kommt. Aus Zeitmangel wollten wir aber das Design nicht mehr \"andern.
