(WS16-01) Autonomes Modellfahrzeug/Allgemein

Aus Verteilte Systeme - Wiki
Wechseln zu: Navigation, Suche
Name Kürzel Hauptrolle im Projekt Zuständigkeit
Ales Koblizek AK Künstliche Intelligenz Spur folgen
André Merdan AM Projektmanagement / Bildverarbeitung gesamte Projektleitung / Objekterkennung
Azeddine Chatar AC Bildbearbeitung Schnittstellenfindung / Optimierung
Ben Stuart BS System IPC, V4L2, Skript & Build-System, GPIO-Taster, Code Review
Erik Bochnia EB System V4L, Park Sensor
Hicham Lazar HL System Systemd
Lucas Noack LN Künstliche Intelligenz / System Schnittstelle zu KI / Programmgerüst, Geschwindigkeit/Lenkeinschlag
Stefan Weiss SW Künstliche Intelligenz Neuronale Netze (Optional)
Thomas Czezor TC Künstliche Intelligenz Startbox, Intersection, Overtake, End
Thomas Zopf TZ System 3D-Druck
Tobias Reichert TR System Logging I und II, PID-Regler, Hardwareerweiterung, KI Review und Parken, Leiter
Victor Klein VK Bildverarbeitung Halteline / Startline
Xu Tu XT Künstliche Intelligenz Parken
Youssef El Amrani YEA Bildverarbeitung Hough Transformation, Entwickler
Yunus Bas YB System Treiber



Einleitung

Dieses Wiki dient zur Dokumentation des Fortschrittes im Wahlprojekt "Autonomes Modellfahrzeug" und wird fortlaufend aktualisiert.

Allgemeine Projektbeschreibung

Autonomie setzt sich aus den Worten autos (selbst) und nomos (Regel oder Gesetz) zusammen.[1] Demnach können autonome Autos als Autos verstanden werden, die in der Lage sind sich autonom und zielorientiert durch eine Umgebung zu navigieren.[2] Mit anderen Worten sind autonome Systeme selbststeuernde Systeme, die ihre Regeln oder Gesetze selbst eingrenzen. Besonders ein Anwendungsfall ist für autonome Systeme besonders interessant. Die Rede ist von der Umsetzung eines autonomen Systems in ein Automobil. An der Idee eines autonomen Autos, welches Insassen eines Autos ohne selbst zu fahren befördert, wird zur Zeit in der Politik stark diskutiert. Nichts desto trotz befassen sich alle Automobilhersteller, sowie große IT-Unternehmen intensiv mit der Umsetzung von autonomen Autos. Auch an der Hochschule RheinMain setzt sich der Fachbereich “Angewandte Informatik” mit diesem Anwendungsfall intensiv auseinander. Die 14 Studenten des Wahlprojekts “Autonomes Modellfahrzeug” bauen innerhalb eines Semesters die Logik für ein autonomes Fahrzeug im Maßstab 1/10.

[1] Vgl. wissen.de (o.J.): Herkunftswörterbuch. autonom. Online verfügbar unter http://www.wissen.de/wortherkunft/autonom, zuletzt geprüft am 01.06.2016. [2] Vgl. Berns, von Puttkamer (2009), S.1

Problemstellung

Die unterschiedlichen Probleme aus Bildverarbeitung, Künstlicher Intelligenz, System und Regelungstechnik werden auf der jeweiligen Teamseite erläutert.

Organisatorisches

Teamtreffen

Regelmäßige Teambesprechungen finden Mittwoch im Raum der technischen Informatik statt.


(Optional Anpassbar - Keine finale Version)

Uhrzeit Tätigkeit Teilnehmer
14:15 - 14:30 Teamsprecher treffen Teamsprecher
14:30 - 14:45 Abteilungsgespräche internen in Unterteams
14:40 - 15:20 Review Teamsprecher, Herr Kaiser, Herr Werner
15:30 - ... Feedback gesamtes Carolo Team

Teamkalendar

  • 31.10.2016 - Vorlesung / Vorstellung Wahlprojekte
  • 02.11.2016 - Vorlesung / Vorstellung Wahlprojekte
  • 15.11.2016 - Carolo-Cup / Anmeldung (fristgemaess)
  • 16.12.2016 - Carolo-Cup / Anmeldung (erhoehte Anmeldegebuehr)
  • 19.12.2016 - Vorlesung / Vorstellung Zwischenergebnisse
  • 21.12.2016 - Vorlesung / Vorstellung Zwischenergebnisse
  • 31.01.2016 - Vorlesung / Vorstellung Projektergebnisse
  • 01.02.2016 - Vorlesung / Vorstellung Projektergebnisse
  • 06.02.2017 - Carolo-Cup / Freies Training
  • 07.02.2017 - Carolo-Cup / Finale
  • 28.02.2017 - Projektende

Grundlagen

Aufbau des Autos

Version 0.1 Auto ubersicht.jpeg


Version 0.2 WS16-10 UML - Gesamt.png

Allgemeine Informationen

Toolchain

Slack

https://carolo-hsrm.slack.com/

Trello

https://trello.com/caroloteam

OpenCV

http://opencv.org/

Git/GitLap

https://zenon.cs.hs-rm.de/CaroloCup/

Allgemein

Git ist eine verteilte Versionverwaltung mit der Möglichkeit mehrere Remote Server bzw. verschiedene Quellen für Quellcode zu haben von denen gepushed und gepulled werden kann.

Für das Wahlprojekt ist es zu empfehlen, das Hautprepository (upstream) zu forken - das entspricht einem clone mit anschließenden push in den eigenen Namespace (origin) - auf den anschließend alle eigene Änderungen gepushed werden. Von diesen Fork können dann Merge Request zum upstream (Hauptrepository) erstellt werden. Ist einmal ein Merge Request erstellt, können weitere Commits nachträglich zum Merge Request hinzugefügt werden.

Ergänzend dazu sollte die Arbeit an einem neuen Feature auf einem eigenen Branch stattfinden. Somit ist es möglich an verschiedenen Feature zu arbeiten und unterschiedliche Merge Request zu erstellen, ohne dass sich diese gegenseitig beeinflussen.

Befehle

Mit upstream ("CaroloCup/libcarolo") ist immer das Haupt-/Ursprungsrepository gemeint, origin ("Max Muster/libcarolo") referenziert immer das Repository im eigenen Namespace.

Für alle Befehle kann eine ausführliche Dokumentation über git Befehl --help angezeigt werden.

submodule

Eine ausführliche Dokumentation findet man hier.

init
add
update
sync
status

Zeige den Status aller lokalen Dateien an.

git status

clone

Lädt das Repository in das aktuelle Verzeichnis.

git clone https://url.de/zu/meinen/repo.git

fetch

Aktualisiert den lokalen origin/master auf den Stand des origin Remote des master Branches.

Keine lokalen Änderungen werden durchgeführt.

git fetch origin master

rebase

Dieser Befehl erfüllt zweierlei Funktionen, allerdings gehen wir nur auf eine Funktionalität den aktuellen lokalen Branche auf einen Stand eines anderen Branches vorzuspulen.

Wir nehmen an man hat ein fetch für den upstream ausgeführt. Dann spult

git rebase upstream/master

den aktuellen Branch auf den Stand von upstream/master vor.

merge

Füge zwei lokale Branches zusammen. Sei FeatureA ein weiterer lokaler Branch und man befindet sich auf momentan auf den lokalen master Branch, dann merged

git merge FeatureA

FeatureA in den master Branch ein.

pull

Dieser Befehl führt einen fetch und anschließend ein merge aus.

Er fetched vom Remote origin die Änderungen des master Branchs und fügt diese in den eigenen lokalen aktuellen Branch ein.

git pull origin master

Ist das push und pull Verhalten auf matching konfiguriert, kann der Befehl auf git pull gekürzt werden.

push

Pushed den aktuellen Branch auf den master Branch des origin Remotes.

git push origin master

Ist ein matching push und pull Verhalten konfiguriert, kann der Befehl auf git push gekürzt werden.

remote

Der Befehl remote ist zum Verwalten von Aliasen für Urls. Es lassen sich beliebige Aliase einrichten.

Zwei Aliase sollten auf jedenfall nicht beliebig gewählt werden. origin für den eigenen Namespace und upstream für das Hauptrepository.

Mit git remote -v können alle bereits exitierenden Remotes angezeigt werden.

Remote hinzufügen

Dadurch wird ein weiterer alias für eine url eingerichtet mit dem Namen origin.

git remote add origin https://url.de/zu/dem/repo.git

Remote ändern

Eine existierender Alias wird auf eine Url gesetzt.

git remote set-url origin https://url.de/zu/dem/repo.git

Remote löschen

Entferne den Remote origin.

git remote remove origin

Formatter & Anderes

clang-check: Tool um Speicherleaks und eventuelle andere Fehlerquellen statisch aufzuspüren.

uncrustify: Code Formatierer für C und C++ Config und 64bit Executable

clang-format: Code Formatierer - Es ist nicht auf den Hochschulrechnern installiert.

indent: Code Formatierer

Wie installiere ich uncrustify auf dem HS-Rechner

  1. git clone https://zenon.cs.hs-rm.de/bstua001/uncrustify-cfg
  2. `uncrustify_x84_64` zu `uncrustify` umbennen
  3. .bashrc öffnen und ergänzen mit PATH=$PATH:/Pfad/zu/uncrustify-cfg

Wenn alles funktioniert hat, sollte `uncrustify --version` eine Version Nummer zurückliefern.

Styles

C

  • Es werden Tabs verwendet mit der Breite 4.
  • Ein Namespace wird wie folgt angegeben.
namespace_doSomething();

Projektverwaltung

Struktur

Vorgehensmodell

Als Vorgehensmodell werden zwei Vorgehensmodelle verwendet. Zum Einen werden wöchentlich Scrum-Sprints abgehalten, zum Anderen werden die Arbeitspakete mit einem Kanbanboard festgehalten. Die Verbindung dieser Vorgehensmodelle nennt sich Scrumban. Informationen zu Scrumban unter Wikipedia - https://en.wikipedia.org/wiki/Scrumban .

Verantwortlichkeiten

Die Verantwortlichkeit der Einhaltung des Vorgehensmodell Scrumban liegt bei Teamsprechern und dem Scrummaster.

Standards

  1. Anforderungen
  2. Entwurf
  3. Implementierung
  4. Test
  5. Ergebnis

Richtlinien

Damit dieses agile Vorgehensmodell funktioniert müssen folgende Richtlinien eingehalten werden:

  • Individuals and interactions - over - processes and tools
  • Working software - over - comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Organisation

Team-Kommunikation

Die Team-Kommunikation läuft ausschließlich über https://carolo-hsrm.slack.com/messages/

Wiki Nutzung

Alle Fragen und Anregungen bitte an: https://carolo-hsrm.slack.com/messages/wiki/

Arbeitszeiterfassung

Jeder Student hat einen wöchentliches Arbeitspensum von ca. 20 h/Woche. Quelle: B. Igler Vorlesung 1 Folie 9 - https://studip.hs-rm.de/sendfile.php?type=0&file_id=87c3106851ac0caafdc048369a14d71d&file_name=wp-16ws-prs-00.pdf

Daher bitte Zeiten einpflegen unter: https://docs.google.com/spreadsheets/d/1o_uSWmtfttu-W8EZQgmr_qdObG9rAtMIdks6LFgAcR4/edit#gid=0 oder http://app.jibble.io/ | usr: andre.merdan@hotmail.de psw:caroloTeam

Anleitung für jibble:

 1 //To start time tracking
 2 /jibble in
 3 
 4 //To stop time tracking
 5 /jibble out
 6 
 7 //To find your tracked time go to
 8 http://app.jibble.io/#people
 9 
10 //For more informations type: 
11 /jibble help

Arbeitszeiterfassung - Überblick

WS16-17 - Timeline15.png
WS16-17 - WochenArbeitszeit15.png
WS16-17 - WochentagsArbeitszeit15.png

Arbeitspakete

Arbeitspakete unter Trello:

System: https://trello.com/b/0ry704Bw/system

KI: https://trello.com/b/MwD5SJmb/kunstliche-intelligenz

BV: https://trello.com/b/HuOYUIW6/bildverarbeitung

Organisation: https://trello.com/b/XI0dttDe/organisation

Projektmanagement

Umsetzung von Scrum

  1. Jeder neue Sprint beginnt und endet am Mittwoch
  2. Jedes Teammitglied muss am Mittwoch festlegen, an welcher/welchen Aufgabe/n er in der jeweiligen Woche arbeitet
  3. Diese Aufgabe/n muss/müssen im Trello auf dem jeweiligen Board dokumentiert werden
  4. Für jede neue Aufgabe muss überlegt werden, wie viel Zeit dafür beansprucht wird
  5. Diese Zeit wird unter https://www.burndownfortrello.com/ festgelegt (Hours Est.)
  6. Am Ende jedes Sprints trägt jedes Teammitglied seine gearbeitete Zeit (Spent) unter https://www.burndownfortrello.com/ ein und/oder korrigiert sie. (Hours Est.)
  7. Im Anschluss beginnt der nächste Sprint

Projektabschluss

Zum Abschluss des Projekts ist jedes Team angewiesen eine Übersicht/Hilfestellung zu erstellen. Diese Übersicht soll unter anderem den nachfolgenden Teams das schnelle Einarbeiten in das Projekt erleichtern. Im Wiki findet sich der Punkt "Projektabschluss" über dem Punkt "Zusammenfassung und Ausblick" wieder. Folgenden Unterpunkte sollen dabei erläutert werden (weitere Punkte können bis zum 22.02.2017 hinzukommen):

Produktabnahme

  • Welchen Punkte wurden fertig entwickelt und im Auto eingebaut und implementiert?
  • Bei welchem Entwicklungsstand befinden sich andere Projektpunkte?

Projektabschlussanalyse

  • Welche Probleme waren zu bewältigen?
  • Ist das Zeitmanagement aufgegangen?
  • Ursachen für zeitliche Abweichungen?

Was man am Anfang wissen sollte

  • Welche Informationen hätte ich am Anfang gerne gehabt?
  • Welche Vorraussetzungen müssen mitgebracht werden?

Slack-Statistiken

WS16-17 - SlackStatisik-Read Write.png WS16-17 - SlackStatisik-Message from People.png WS16-17 - SlackStatisik-Messages from Integrations.png