Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Frameworks Vorbereitungskurs auf das AUV12 Projekt

Ähnliche Präsentationen


Präsentation zum Thema: "Frameworks Vorbereitungskurs auf das AUV12 Projekt"—  Präsentation transkript:

1 Frameworks Vorbereitungskurs auf das AUV12 Projekt
DFKI Bremen & Universität Bremen Robotics Innovation Center Dipl.-Inf. Matthias Goldhoorn Director: Prof. Dr. Frank Kirchner

2 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

3 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

4 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

5 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

6 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

7 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

8 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

9 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

10 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.

11 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!

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

13 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

14 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

15 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“)

16 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

17 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

18 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

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

20 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})

21 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/

22 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

23 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

24 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 (0x00007f8cb ) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f8cb ) 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à

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


Herunterladen ppt "Frameworks Vorbereitungskurs auf das AUV12 Projekt"

Ähnliche Präsentationen


Google-Anzeigen