Frameworks Vorbereitungskurs auf das AUV12 Projekt DFKI Bremen & Universität Bremen Robotics Innovation Center Dipl.-Inf. Matthias Goldhoorn Director: Prof. Dr. Frank Kirchner www.dfki.de/robotics robotics@dfki.de

Wozu ein Framework? Was ist ein „Robotik Framework“? Ein Framework stellt ein Grundgerüst für die eigenen Anwendungen bereit Es Abstrahiert von niederen Ebenen Es stellt optimalerweise Tools zur Verfügung die einem das Leben einfacher machen Es besteht zumeist aus mehreren miteinander Interagierender Bestandteile

Wozu ein Framework? Typische (Software-) Probleme der Robotik Interprozesskommunikation Intersystemkommunikation Noch schlimmer heterogene Systeme Datenvisualisierung Datenspeicherung Logging Datenauswertung zuvor akquirierter Daten Replay von Logs Datensyncronisation

Wozu ein Framework? Typische (Software-) Probleme der Robotik Plan-/Missionsmanagement Welche Aktion wähle ich als nächste, was passiert wenn sie fehlschlägt? Systemsicherheit, wann ist mein System in einem sicheren zustand? Debugging Simulation Entwicklung von Generischen Komponenten zwecks Wiederverwendung Rad nicht stetig neu erfinden

Wozu ein Framework - Details Interprozesskommunikation/Intersystemkommunikation Abstraktion vom Serialisieren/Deserialisieren & Marshalling Bereitstellung „genormter“ Datenstrukturen/Nachrichten Bereitstellung einer Datentransportschicht und Abstraktion dessen Definition des Datenflusses, wer bekommt welche Daten 2 Varianten: Publisher/Subscriber Explizites Verbindungsmanagement

Wozu ein Framework - Details Datenvisualisierung Dank der Bereitstellung „genormter“ Nachrichten allgemeine und spezialisierte Visualisierungen möglich Teils abstrahierter Zugriff auf Daten zur einfachen Visualisierung Datenanzeige auch ohne Spezialisierte Anzeige und ohne komplexe Programmierung möglich Idealerweise Identische Module nutzbar zur online und offline Visualisierung

Wozu ein Framework - Details Datenspeicherung und Datenauswertung Ein gutes Framework sollte das Transparente aufzeichnen aller Datenströme ermöglichen Ein noch besseres Framework sollte das abspeichern und direkte wiederabspielen innerhalb der gleichen Module ermöglichen. Kein Unterschied zwischen Online-/Offlinemodulen Konvertierungsfunktionalität für „alte“ Logdaten. Auch Nachrichten Typen können sich ändern, ohne dass die Logs unbrauchbar werden sollten

Wozu ein Framework - Details Datensynchronisierung Warum Synchronisieren? Sensoren erzeugen Daten nicht Zeitgleich Verschiedene „Uhren“ der Sensoren/Systeme Verschiedene Latenzen Inhalt des Systeme Diverse Filter benötigen Daten eines definierten Zeitpunktes Vermeidung von vermischen von verschiedene Zeitpunkten Camerat und Sonart+1

Wozu ein Framework - Details Plan-/Missionsmanagement Intelligenz eines Systems Was für Module müssen wann in welchem Modus gestartet werden Welche verhalten benötigt welche Daten/Module Welche Module behindern sich gegenseitig Welches verhalten soll wann gestartet/gestoppt werden Was passiert wenn ein benötigtes Modul den zustand (in einem Fehlerzustand) wechselt

Wozu ein Framework - Details Debugging und Simulation Hängen (oft) zusammen Das Framework sollte Funktionalität zum durchspielen aller zustände der Module bieten um das Gesamtsystem möglichst detailliert testen zu können. Debugging beschränkt sich nicht nur auf abstürze, sondern auch fehlverhalten der Module Simulation ist nicht nur die „Physikalische“ Simulation des gesamt Systems. Auch einzelne Sensordaten können Simuliert werden, ohne das Gesamtsystem betrachten zu müssen.

Wozu ein Framework - Details Entwicklung von generischen Komponenten Projektübergreifende Wiederverwendbarkeit von ganzen Modulen wie z.B. Positionsregelung. Früher wurden „Listen“ wiederverwendet, heute ganze Softwarekomponenten Dazu möglichst generisch entwickeln: Kein Avalon-Control, sondern ein AUV-Control und dynamische Parametrisierung der Konfiguration/Regelung. Framework liefert „Grundstruktur“ für die Komponenten Erleichtert die generische Implementierung Generische Entwicklung Reduziert die Entwicklungszeit ganzer Systeme dank Wiederverwendung enorm!

Framework - Konkret GANZ unten Entwicklung von generischen Komponenten Wo fangen wir an? GANZ unten

Libraries im Linux Eine Grundregel im ROCK Framework: Sämtliche Kern - Funktionalität wird in normalen Libraries unabhängig von der Datenübertragung oder Nutzung entwickelt Erleichtert die Wiederverwendbarkeit auch bei einem Framework wechsel und sogar außerhalb des Frameworks

Libraries im Linux Typische Linux Grundstruktur: <base>/include Typischer ablageort für Header <base>/lib Dynamische Libraries <base>/lib/pkgconig Ablageort der pkg-config Dateien (.pc) <base>/bin Binaries (ausführbare Programme) Das <base> Verzeichnis ist nicht auf / oder /usr beschränkt, es kann beliebig erweitert werden. ROCK installiert dabei immer im <projektordner>/install

Libraries im Linux Starten wir mit CMake Ein CMake Projekt wird über die CMakeLists.txt definiert Grundbefehle: cmake_minimum_required(VERSION 2.6) add_library(<TARGET> SHARED <SOURCES>) add_executable(<TARGET> <SOURCES>) target_link_libraries(<TARGET> <LIBRARIES>) install(TARGETS <TARGET> LIBRARY DESTINATION lib) install(FILES <HEADERS> DESTINATION include) Bereitgestelltes Projekt damit zum kompilieren bringen. (erstmal nur „test-library“)

Libraries im Linux Starten wir mit CMake Für den Kurs benutzen wir den ~/framework Ordner (bitte anlegen) Bei allen Frei? Struktur: framework/test-library/CMakeLists.txt Kompilieren im dedizierten build Ordner (CMake Standart) mkdir build cd build Nun folgt das Kompilieren cmake ../ -DCMAKE_INSTALL_PREFIX=~/framework/install make install

Libraries im Linux Starten wir mit CMake Nutzung unseres Projektes als Library Wieder Beispielcode „application“ Fehlermeldung: /home/goldhoorn/framework/application/main.cpp:1:26: fatal error: Calculator.hpp: Datei oder Verzeichnis nicht gefunden compilation terminated. make[2]: *** [CMakeFiles/Calculator-v2.dir/main.cpp.o] Fehler 1 make[1]: *** [CMakeFiles/Calculator-v2.dir/all] Fehler 2 make: *** [all] Fehler 2

Libraries im Linux Starten wir mit CMake Was ist passiert, das System kann den Header nicht finden. Wie auch, das System sucht idr. nur /usr/include und /include Lösung: pkg-config Standardisiertes Linux System zum Bereitstellen von Zusatzinformationen von Libraries. Interagiert mit CMake Stellt Variablen mit Zusatzinformationen für den Compiler bereit

Libraries im Linux Starten wir mit CMake Erstellung einer pkg-config Datei (auch bereitgestellt) prefix=@CMAKE_INSTALL_PREFIX@ exec_prefix=@CMAKE_INSTALL_PREFIX@ libdir=${prefix}/lib includedir=${prefix}/include Name: Calculator Description: Test Project for Framework Project Version: @PROJECT_VERSION@ Libs: -L${libdir} -l<NAME_OF_LIBRARY> Cflags: -I${includedir} Erweiterung der CMakeLists.txt um: CONFIGURE_FILE(calculator.pc.in calculator.pc @ONLY) INSTALL(FILES ${CMAKE_BINARY_DIR}/calculator.pc DESTINATION lib/pkgconfig)

Libraries im Linux Starten wir mit CMake Nochmal Kompilieren und zurück zum „application“ Project. Fehler unverändert Ein paar Anpassungen in der CMakeLists nötig include(FindPkgConfig) pkg_check_modules(<MODUL> REQUIRED "<PKG_NAME>") include_directories(${<MODUL>_INCLUDE_DIRS})

Libraries im Linux Starten wir mit CMake Nochmal Kompilieren und zurück zum „application“ Project. Neuer Fehler make: Entering directory `/home/goldhoorn/framework/application/build' -- checking for module 'calculator' -- package 'calculator' not found Pkg-config benötigt korrekt gesetzt Umgebungsvariable zum finden der .pc Dateien. export PKG_CONFIG_PATH=~/framework/install/lib/pkgconfig/

Libraries im Linux Starten wir mit Cmake Nochmal Kompilieren und zurück zum „application“ Project. Nochmal neuer Fehler CMakeFiles/Calculator-v2.dir/main.cpp.o: In function `main': main.cpp:(.text+0x46): undefined reference to `Calculator::Calculator()' main.cpp:(.text+0x80): undefined reference to `Calculator::add(int, int)' main.cpp:(.text+0x117): undefined reference to `Calculator::~Calculator()' main.cpp:(.text+0x131): undefined reference to `Calculator::~Calculator()' Warum, schauen wir rein im detail Im build Ordner: make VERBOSE=1 /usr/bin/c++ CMakeFiles/Calculator-v2.dir/main.cpp.o -o Calculator-v2 –rdynamic Library wurde nicht mit gelinkt, mein -l in der linkerzeile vorhanden

Libraries im Linux Starten wir mit CMake Nochmal Kompilieren und zurück zum „application“ Project. Nochmal CMakeLists erweitern, dass die entfernte Library mit genutzt wird. (Vor dem add_executable, da CMake wie ein script arbeitet) link_directories(${<MODUL>_LIBRARY_DIRS}) target_link_libraries(<TARGET> ${<MODUL>_LIBRARIES}) …und nochmal kompilieren mit make VERBOSE=1 /usr/bin/c++ -I/home/goldhoorn/framework/install/include -o CMakeFiles/Calculator-v2.dir/main.cpp.o -c /home/goldhoorn/framework/application/main.cpp /usr/bin/c++ CMakeFiles/Calculator-v2.dir/main.cpp.o -o Calculator-v2 -rdynamic -L/home/goldhoorn/framework/install/lib -lCalculator -Wl,-rpath,/home/goldhoorn/framework/install/lib

Libraries im Linux Starten wir mit CMake Das war es, wir haben ein Binär Programm, welches eine externe Library nutzt Calculator-v2 Woher wissen wir nun das die Library dynamisch genutzt wird? ldd -r Calculator-v2 linux-vdso.so.1 => (0x00007fff61fff000) libCalculator.so => /home/goldhoorn/framework/install/lib/libCalculator.so (0x00007f8cb2337000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f8cb2004000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8cb1d81000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8cb1b6b000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8cb17e4000) /lib64/ld-linux-x86-64.so.2 (0x00007f8cb253a000) et voilà

Dankeschön! Nächstes mal mehr Librarys und „sauberer“ Code DFKI Bremen & Universität Bremen Robotics Innovation Center Director: Prof. Dr. Frank Kirchner www.dfki.de/robotics robotics@dfki.de