Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "Frameworks Vorbereitungskurs auf das AUV12 Projekt DFKI Bremen & Universität Bremen Robotics Innovation Center Dipl.-Inf. Matthias Goldhoorn Director:"—  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 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 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 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 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 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 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 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 ► Camera t und Sonar t+1

9 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 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 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 12 Framework - Konkret Entwicklung von generischen Komponenten  Wo fangen wir an? GANZ unten

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

15 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( SHARED ) ► add_executable( ) ► target_link_libraries( ) ► install(TARGETS LIBRARY DESTINATION lib) ► install(FILES DESTINATION include)  Bereitgestelltes Projekt damit zum kompilieren bringen. (erstmal nur „test-library“)

16 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 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 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 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 Cflags: -I${includedir}  Erweiterung der CMakeLists.txt um: CONFIGURE_FILE(calculator.pc.in INSTALL(FILES ${CMAKE_BINARY_DIR}/calculator.pc DESTINATION lib/pkgconfig)

20 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( REQUIRED " ") include_directories(${ _INCLUDE_DIRS})

21 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 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 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(${ _LIBRARY_DIRS}) target_link_libraries( ${ _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 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 DFKI Bremen & Universität Bremen Robotics Innovation Center Dipl.-Inf. Matthias Goldhoorn Director:"

Ähnliche Präsentationen


Google-Anzeigen