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

robotics@dfki.de

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

robotics@dfki.de