Upload
pankraz-geen
View
106
Download
0
Embed Size (px)
Citation preview
FrameworksVorbereitungskurs 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
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
• DatensynchronisierungWarum 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
• 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)
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)
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ötiginclude(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 FehlerCMakeFiles/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-v2linux-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