Projektdokumentation im Robotiklabor MINTgrün

Die Projektdokumentation soll die Ergebnisse eurer Arbeit zusammenfassen und nach außen präsentieren. Sie soll so geschrieben sein, dass ein technisch interessierter Außenstehender ohne Wissen über eurer Projekt verstehen kann, was ihr gemacht habt und alle nötigen Informationen hat, um euer Projekt nachzubauen oder weiter zu entwickeln.

Für die Projektdokumentation bekommt ihr maximal 20 Punkte. Insgesamt gibt es im Kurs 100 Punkte, ihr braucht 50%, um zu bestehen. Die Lehrveranstaltung wird im Sommersemester 2020 nicht benotet.

Macht bitte eine neue Seite für eure Projektdokumentation. Sie gehört nicht auf eure Projektplanung-Seite.

Ihr habt bis zum 26.07. Zeit, die erste Version eurer Doku vorzubereiten. Dann wird Darya sie lesen und euch in ca. 2 Tagen in Wiki Kommentare geben. Ihr bekommt dazu eine ISIS-Nachricht. Danach habt ihr bis zum 09.08. Zeit, die Endversion der Doku vorzubereiten. Falls ihr mehr Zeit braucht (z.B. wegen Prüfungen), schreibt Darya eine E-Mail.

Die Projektdokumentation orientiert sich grob an einer wissenschaftlichen Arbeit mit Einleitung, Methodenteil, Ergebnissen und Fazit. Zur besseren Übersichtlichkeit sollte die Seite durch Überschriften gegliedert werden. Die folgenden Inhalte gehören rein:

• Kurze Beschreibung der Aufgabenstellung, die das Programm hat bzw. löst (ca. 1/2 „Bildschirmseite“)
• u.U. Hinweise und Links auf schon existierende ähnliche Arbeiten bzw. Projekte aus den alten Semestern

• Welche Aufgaben waren zu lösen (ganz knapp)
• Welche Aufgaben wurden bewusst ausgeklammert?
• Idealerweise eine schematische Darstellung davon, was euer Programm macht (z.B. ein Flussdiagramm)

Hier geht ihr ins Detail. Jeder wichtige Bestandteil eurer Lösung (z.B. „GUI“, „Erkennung von X“, „Berechnung von Y“, „Modell für die Simulation von Z, „Anwendung des Algorithmus ABC“ ) bekommt einen eigenen Abschnitt.

Dabei sollte kein für die Funktion wesentlicher Teil komplett unerwähnt bleiben. Erklärt insbeondere diejenigen Teile ausführlich, in die ihr besonders viel Hirnschmalz gesteckt habt, oder zu denen es interessante Zwischenergebnisse (z.B. Bilder) gibt.

• Welche besonderen technischen, mathematischen oder programmiererischen Anforderungen standen bei der Arbeit im Vordergrund und wie wurden sie gelöst?
• Sprache: Technisch detailliert, präzise und eindeutig, aber knapp formuliert.
• Abbildungen: Oft sagt eine Skizze oder eine Zeichnung mehr als tausend Worte! Sie sollte im aber einen Bezug zum Text haben und aus sich heraus verständlich sein.
• Hierher gehören auch Grafiken, die die Zwischenergebnisse darstellen, die in eurem Projekt entstanden sind.

• Endstand des Projekts: Was leistet die entwickelte Lösung und woran scheitert sie?
• Falls die Qualität des Ergebnisses in Zahlen zu messen ist, gehören diese hierhin.
• Ausblick: Wo bestehen Verbesserungs- oder Erweiterungsmöglichkeiten? Wie könnte man das Projekt weiter entwickeln (z.B. in den nachfolgenden Semestern)?

Eine Sammlung des Kompletten Programmcodes gehört zu eurer Dokumentation. Wenn ihr wollt, könnt ihr dafür eine gesonderte Seite, so dass sie verfügbar sind, ohne den Lesefluss allzu sehr zu stören.

Hier solltet Ihr eine lauffähige Version eures Codes inkl. aller verwendeten Libraries als .zip-Datei zum Download anbieten. Selbst wenn ihr eine git-Seite habt, ladt bitte den Code herunter als .zip und ladet hier hoch. Grund: der Code soll zugänglich sein, selbst wenn ihr z.B. euren github-Account löscht.

• Es geht nicht darum, jemanden zu beeindrucken, sondern etwas möglichst verständlich und präzise zu erklären. Am besten gelingt das mit einer knappen, präzisen, aber freundlichen Sprache ohne allzuviele Floskeln.
• Falls Ihr irgendetwas gemessen oder berechnet habt, gehört das in die Dokumentation
• Falls Ihr Informationen verwendet, die ihr nicht selbst durch das Ausprobieren oder Nachdenken gefunden habt, sollten diese mit einer Quelle belegt werden. Die Quellen könnt ihr auch als Links im Wiki-Text angeben, z.B. so: TU Berlin (Wiki-Syntax: [[https://www.tu-berlin.de | TU Berlin]]). Das bezieht sich natürlich auch auf Bilder, die ihr nicht selbst erstellt habt. Da das Urheberrecht ein komplexes Thema ist, ist es besser, die entsprechenden Seiten oder Videos zu verlinken, als die dort stehenden Bilder/Videos zu kopieren.
• Fachwörter, die ihr benutzt, solltet Ihr auch verstanden haben. Im Zweifelsfall besser nachschlagen, als Unsinn zu schreiben.
• Skizzen dürfen bei uns durchaus auch handgezeichnet sein. Sie sehen am besten aus, wenn sie auf weißem Papier gezeichnet sind und nach dem Scannen der Weißpunkt so gesetzt wird, dass der Hintergrund reinweiß ist, z.B. so mit GIMP. GIMP ist ein open-source Bildverarbeitungsprogramm, welches auch sonst bei der Vorbereitung der Abbildung für die Dokumentation nützlich sein kann.
• Alle Abbildungen und Diagramme sollten nummeriert und mit einer kurzen Bildunterschrift versehen sein, die die wesentlichen Aussagen und Inhalte der Grafik knapp erklärt, z.B. so wie in Abb. 1 (s. den Wiki-Quelltext, wie der Link an der Stelle der Abbildungsnummer erstellt wurde):
  

Abbildung 1: Arduino-MOSFET-Schalter für induktive Lasten

• Das Gleiche gilt für Tabellen – sie bekommen eine eigene Nummerierung.
• Bitte verteilt eure Dokumentation nicht auf viele Unterseiten, sie ist dann schwer zu lesen.

• Wir wollen von euch eine Wiki-Seite! Also keine PDFs, Papierausdrucke oder Word-Dateien!

• Eure Wiki-Seite wird spätestens zum Anfang des nächsten Semesters öffentlich geschaltet werden, und zwar unter dem Punkt „Projekten aus den vergangenen Semestern“ in Wiki. Das bedeutet, falls ihr Bilder von euch selbst erzeugt habt und nicht wollt, dass diese öffentlich werden, schreibt Darya eine E-Mail. Falls ihr wollt, dass eure Namen auf der Projekt-Doku-Seite auftauchen, so schreibt diese dort.
• Falls ihr Fragen zur Wiki-Formatierung habt, helfen wir euch gerne. Schreibt eine E-Mail an Darya.

• soccerbot: Gute Schwerpunktsetzung und Erklärungen anhand von Formeln und die vielen Abbildungen.
• malokal: Sehr schöne Bilder, sehr Umfangreich, es fehlt jedoch eine quantitative Schätzung des sich ansammelnden Lokalisiserungsfehlers
• beerbot:Großer Detailumfang, viele guten Abbildungen. Der Aufbau ist in der Grundstruktur gut. Der Endstand ist ehrlich dargestellt, eine tiefere Analyse der Fehlerursachen fehlt aber.
• Halli Galli: Gute Abbildungen, aber eine Diskussion der Ergebnisse und Probleme hätte ausführlicher sein sollen.
• CATcher: Gute schematische Abbildungen, ausführliche Diskussion der Ergebnisse.