diff --git a/LeonardoMixerIO/doc/Dokumentation_Systemtechnik.bib b/LeonardoMixerIO/doc/Dokumentation_Systemtechnik.bib
index 1c75d1fc76895c5bc68caa27c5d8093c401ca5e9..ce74a23e8a04b47ce679015154ee547102a5dd60 100644
--- a/LeonardoMixerIO/doc/Dokumentation_Systemtechnik.bib
+++ b/LeonardoMixerIO/doc/Dokumentation_Systemtechnik.bib
@@ -105,3 +105,17 @@
Url = {http://www.multiwii.com/wiki/index.php?title=Multiwii_Serial_Protocol},
Urldate = {2016-10-03}
}
+
+@online{wikipedia,
+ Author = {{Wikipedia}},
+ Title = {Wikipedia-Eintrag zur Funkfernsteuerung},
+ Url = {https://de.wikipedia.org/wiki/Funkfernsteuerung},
+ Urldate = {2017-03-07}
+}
+
+@online{wikipedia1,
+ Author = {{Wikipedia}},
+ Title = {Wikipedia-Eintrag zur Flugdynamik von Quadrocoptern},
+ Url = { https://en.wikipedia.org/wiki/Quadcopter#Flight_dynamics},
+ Urldate = {2017-03-07}
+}
diff --git a/LeonardoMixerIO/doc/Dokumentation_Systemtechnik.pdf b/LeonardoMixerIO/doc/Dokumentation_Systemtechnik.pdf
index f0d5eadea71e374c730a570bd04e4cc16435e260..e3bc35ae922d1c6e4c35b27a9324d4f1425c8866 100644
Binary files a/LeonardoMixerIO/doc/Dokumentation_Systemtechnik.pdf and b/LeonardoMixerIO/doc/Dokumentation_Systemtechnik.pdf differ
diff --git a/LeonardoMixerIO/doc/Dokumentation_Systemtechnik.tex b/LeonardoMixerIO/doc/Dokumentation_Systemtechnik.tex
index ff158384a14f24d6eea8fc3565cd917e8a6b4571..c3cfa59bb397664455b2ea52cb8306887d0d6f20 100644
--- a/LeonardoMixerIO/doc/Dokumentation_Systemtechnik.tex
+++ b/LeonardoMixerIO/doc/Dokumentation_Systemtechnik.tex
@@ -12,6 +12,11 @@
\def\runcourse{Eingebettete Systeme}
\def\runcategory{Hausarbeit}
+%% Allow for a greater part of the page to be occupied by figures
+\renewcommand{\topfraction}{0.8}
+\renewcommand{\bottomfraction}{0.8}
+\renewcommand{\textfraction}{0.2}
+
%% Packages
\usepackage{layout/BOmodern} % modern HS Bochum themed document template designed for assignments and documentations
\usepackage{amsmath}
@@ -73,26 +78,26 @@ Motiviert ist die Entwicklung dieses Systems durch die Notwendigkeit einer
Signalkonvertierung und -verarbeitung für ein bedingt autonomes,
unbemanntes Flugobjekt. An dieser Stelle der Verweis auf das Schwesterprojekt
Visual Based Landing System -- kurz VBLS\footnote{VBLS - \url{https://gitlab.cvh-server.de/lf.ps/vbls/tree/master/Visual-Based-Landing-System}}.
-Um einen sicheren Betrieb dieses zu ermöglichen, sind manuelle Steuerimpulse von
+Um dessen sicheren Betrieb zu ermöglichen, sind manuelle Steuerimpulse von
einer konventionellen Fernsteuerung mit von einer Android Applikation
generierten Steuerimpulsen zu kombinieren. Hierbei muss ein manuelles
Eingreifen durch den Menschen jederzeit möglich sein, darüber hinaus
muss die Signalverarbeitung in einem fest definierten Zeitrahmen
abgeschlossen werden. Ein mögliches Einsatzgebiet ist beispielsweise
die Schnittstelle zur Integration diverser Assistenzsysteme in eine
-manuelle Steuerung (vgl. bspw. Spurhalteassistenzsystem im Auto).
+manuelle Steuerung (vgl.\ bspw. Spurhalteassistenzsystem im Auto).
\chapter{Grundlagen}
\section{Echtzeitfähigkeit}
-Die Definition von Echtzeit nach DIN 44300 lautete:
+Die Definition von Echtzeit nach DIN 44300 lautet:
\begin{quote}
Unter Echtzeit versteht man den Betrieb eines Rechensystems, bei dem Programme
zur Verarbeitung anfallender Daten ständig betriebsbereit sind, derart, dass die
Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verfügbar sind.
Die Daten können je nach Anwendungsfall nach einer zeitlich zufälligen Verteilung
oder zu vorherbestimmten Zeitpunkten anfallen.
- (vgl. DIN 44300 (Informationsverarbeitung), Teil 9 (Verarbeitungsabläufe))
+ (vgl.\ DIN 44300 (Informationsverarbeitung), Teil 9 (Verarbeitungsabläufe))
\end{quote}
Wie obenstehende Definition verdeutlicht, sagt der Begriff der Echtzeit nicht direkt
etwas über die Geschwindigkeit eines Systems aus. Er beschreibt lediglich ein System,
@@ -108,8 +113,12 @@ Beim kooperativen Multitasking können Tasks garnicht oder nur dann unterbochen
wenn sie dazu bereit sind. Unkooperative Tasks können somit das ganze System anhalten.
Dieses Verfahren ist nur dann für echtzeitkritische Anwendungen geeignet, wenn die
einzelnen Tasks selbst so programmiert sind, dass ihre Ausführungszeit begrenzt ist.
+Weiterhin muss darauf geachtet werden, dass keine Tasks aufgrund von Nichtbeachtung
+bzw.\ Nichtausführung verhungern (engl.: to starve).
+Dieser Starvation ist vorzubeugen, indem Tasks nicht nur statisch, sondern dynamisch
+unter Berücksichtigung ihrer letzten Ausführungszeit, priorisiert werden.
-subsection{Präemptives Multitasking}
+\subsection{Präemptives Multitasking}
Beim präemptiven Multitasking können Tasks jederzeit unterbrochen werden. In Kombination
mit bspw. Hardware-Interrupts lässt sich so eine harte Echtzeitfähigkeit realisieren.
@@ -118,7 +127,7 @@ Als Radio Control -- alternativ Remote Control -- bezeichnet man im Allgemeinen
die Steuerung aus der Ferne, mittels Funk- oder Licht-Signalen.
Nikola Tesla soll bereits 1898 ein funkferngesteuertes Schiffsmodell vorgeführt haben.
Einen guten Überblick über die historische Entwicklung der Fernsteuerungstechnik
-bietet folgender Wikipedia-Eintrag: \url{https://de.wikipedia.org/wiki/Funkfernsteuerung}
+bietet folgender Wikipedia unter dem Stichwort Funkfernsteuerung \cite{wikipedia}.
\subsection{RC im Modellflug auf Stand der Technik}
Die Digitalisierung hat auch im Modellbau Einzug gehalten. So arbeiten alle heute
@@ -134,7 +143,7 @@ Nach derzeitigem Stand sind mit diesem digtalen Verfahren Funkübertragungen von
bis zu 32 Kanälen über Entfernungen mehrerer Kilometer möglich.
Die Auflösung der einzelnen übertragenen Kanäle kann hierbei variieren, typisch
sind in höherwertigen Anlagen Auflösungen von bis zu 4096 Schritten -- 12 Bit --
-bei Wiederholraten teilweise signifikant größer 50Hz.
+bei Wiederholraten teilweise deutlich über 50Hz.
\subsection{Übersicht etablierter Protokolle}
Die folgend beschriebenen Protokolle beziehen sich ausschließlich auf die Datenübertragung
@@ -154,7 +163,7 @@ Puls-Weiten Modulation -- kurz PWM -- bezeichnet ein Verfahren, bei dem mit eine
gegebenen Frequenz Pulse variabler Länge generiert werden. Die Länge des Pulses
ist proportional zu übertragenden Wert.
Im Modellbau findet dieses Verfahren zum einen zur Leistungsregelung von Gleichstrom-Motoren
-Verwendung, zum anderen stellt es den etablierten Standard der Ansteuerung von Servo-Motoren (siehe \ref{fig:waveform-pwm})
+Verwendung, zum anderen stellt es den etablierten Standard der Ansteuerung von Servo-Motoren (siehe Abb.\ \ref{fig:waveform-pwm})
und Drehzahlstellern, wie etwa bei einem Quadrocopter, von Seiten eines RC-Empfängers
oder einer Flugsteuerung dar.
\begin{figure}[hb]
@@ -171,9 +180,9 @@ oder einer Flugsteuerung dar.
Puls-Positions Modulation -- kurz PPM -- wird oft auch als PWM-Summensignal bezeichnet.
Es findet im Modellbau beispielsweise Verwendung, um bis zu neun PWM-Signale über
eine einzige Leitung zu senden. Dies geschieht durch Aneinanderreihung der unter PWM
-beschriebenen Pulse (siehe \ref{fig:waveform-ppm}). Aufgrund der simplen Verdrahtung
+beschriebenen Pulse (siehe Abb.\ \ref{fig:waveform-ppm}). Aufgrund der simplen Verdrahtung
stellt es eine beliebte Möglichkeit dar, Flugsteuerung und RC-Empfänger zu verbinden.
-\begin{figure}[hb]
+\begin{figure}[hbt]
\centering
\includegraphics[page=1,trim=3cm 4.5cm 7cm 20.5cm,clip,width=\textwidth]{references/MTN004.pdf}
\caption{Typische Wellenform eines im Modellbau verwendeten PPM-Summen-Signals~\cite[][1]{mec2001}}
@@ -188,37 +197,23 @@ UART eines Mikrocontrollers generiert und gelesen werden können.
Jedes dieser Protokolle ist dazu geeignet, mindestens sechs Steuerkanäle zu übertragen.
\begin{itemize}
\item{Spektrum-Remote-Receiver\\
-Das Spektrum-Remote-Receiver Protokoll wird von sog. Satelliten-Empfängern des Herstellers
-Spetrum bzw. Horizon Hobby und dessen Nachahmern verwendet, um mit einem Hauptempfänger
+Das Spektrum-Remote-Receiver Protokoll wird von sog.\ Satelliten-Empfängern des Herstellers
+Spektrum bzw. Horizon Hobby dazu kompatiblen Systemen verwendet, um mit einem Hauptempfänger
oder einem Flugcontroller zu kommunizieren.
Ursprünglich diente es lediglich der Erhöhung der Ausfall- und Übertragungssicherheit
der Funkverbingung zwischen Fernsteuerung und Empfänger durch das Vernetzen mehrerer,
Satelliten-Empfänger mit einem Hauptempfänger.
+
Mehrere erfolgreiche Reverse-Engineering Ansätze ermöglichten jedoch bald die unabhängige
Verwendung dieser kostengünstigen Satellitenempfänger mit Flugsteuerungen.
Horizon Hobby reagierte schließlich mit dem begrüßenswerten Entschluss, eine offizielle
Spezifikation dieses Protokolls mitsamt einer rudimentären Implementierungsanleitung
-zu veröffentlichen.
-\begin{quote}
-In normal operation, the Spektrum remotes issue a 16-byte data packet every 11ms or 22ms, depending
-upon the selected protocol. The packet is transmitted at 125000bps, 8 bits, No parity, 1 stop (8N1).
-For those UARTs which are not capable of that speed, they will also work at the more-standard
-115200bps. When no data is received, the remote does not transmit anything.
-\cite[][2]{spek2016}
-\end{quote}
+zu veröffentlichen.\cite[][2]{spek2016}
}
\item{SRXL\\
Das Serial Receiver Link Protocol stellt ein offenes Protokoll dar, mit dem Ziel die Kommunikation zwischen
Modellbau-Komponenten unterschiedlicher Hersteller zu ermöglichen. Es können in
-SRXL Version 2 bis zu 16 Kanäle übertragen werden.
-\begin{quote}
-Die [SRXL-]Schnittstelle ist eine asynchrone serielle Eindraht Schnittstelle mit den Pegeln
-0V für Low, 3,3V für High und den Übertragungsparametern 115200Kbit/s, 8 Datenbits,
-keine Parität, 1 Stopp-Bit. Sobald der Empfänger ein Signal empfängt, werden die
-seriellen Daten zyklisch ausgegeben. Bei „FastResponse EIN“ im 14ms Takt und bei
-„FastResponse AUS“ im 21ms Takt.
-\cite[][1]{multiplex2013}
-\end{quote}
+SRXL Version 2 bis zu 16 Kanäle übertragen werden.\cite[][1]{multiplex2013}
}
\item{MSP\\
Das MultiWii-Serial Protokoll ist eine offenes Protokoll zur Kommunikation unterschiedlichster
@@ -226,44 +221,33 @@ Komponenten mit einer Flugsteuerung, auf welcher MultiWii selbst oder eine der F
läuft.
Es dient nicht primär der Übertragung von Kanaldaten, es bietet darüber hinaus zahlreiche
Kommandos zur Konfiguration der Flugsteuerung und zur Abfragung von Telemetriedaten.
+
Das MSP ermöglicht jedoch das Überschreiben der auf der Flugsteuerung vorliegenden Kanaldaten
und somit auch eine direkte Steuerung des entsprechenden Fluggerätes.
-Leider gibt es zu dem MSP keine zusammenhängende Dokumentation, ein Wiki-Eintrag\footnote{\url{http://www.multiwii.com/wiki/index.php?title=Multiwii_Serial_Protocol}}
-beschreibt jedoch gut die zur Verfügung stehenden Kommandos, und in dem MultiWii-Forum\footnote{\url{http://www.multiwii.com/forum/viewtopic.php?f=8&t=1516}}
-gibt es einen entsprechenden Beitrag mit sporadischer Aktivität.
+Leider gibt es zu dem MSP keine zusammenhängende Dokumentation, ein Wiki-Eintrag (vgl.\ \cite{multiWii2015})
+beschreibt jedoch gut die zur Verfügung stehenden Kommandos, und in dem MultiWii-Forum
+gibt es einen entsprechenden Beitrag (vgl.\ \cite{multiWii2012}) mit sporadischer Aktivität.
}
\end{itemize}
\section{Arduino Leonardo}
Der Arduino Leonardo stellt eine Entwicklungsplatine für den Atmel-Atmega-32u4 dar.
-\begin{quote}
-The Arduino Leonardo is a microcontroller board based on the ATmega32u4 [...].
-It has 20 digital input/output pins (of which 7 can be used as PWM outputs and 12
-as analog inputs) [and] a 16 MHz crystal oscillator [...].
-It contains everything needed to support the microcontroller [...].
-
-The Leonardo differs from all preceding boards in that the ATmega32u4 has built-in
-USB communication [...]. This allows the Leonardo to appear to a connected computer
-[or mobile phone] as [...] a virtual (CDC) serial / COM port.
-
-(vgl. \url{https://www.arduino.cc/en/Main/arduinoBoardLeonardo})
-\end{quote}
Gewählt wurde der Leonardo, da er der günstigste und kompakteste Arduino ist, welcher
neben einer in Hardware implementierten seriellen Schnittstelle auch eine zweite
serielle Schnittstelle in Form einer virtuellen USB-CDC Schnittstelle bietet.
Diese ist essentiell für die Kommunikation des RC-Mischers mit dem Mobiltelefon.
-Beide Schnittstellen sind auf dem Blockdiagramm des Atmega 32u4 (siehe \ref{fig:block-diag-32u4})
+Beide Schnittstellen sind auf dem Blockdiagramm des Atmega 32u4 (siehe Abb.\ \ref{fig:block-diag-32u4})
zu erkennen, namentlich USB2.0 und USART1.
-\begin{figure}[hb]
+\begin{figure}[h]
\centering
\includegraphics[page=4,trim=1cm 8.4cm 1cm 3.5cm,clip,width=\textwidth]{references/Atmel-7766-8-bit-AVR-ATmega16U4-32U4_Datasheet.pdf}
\caption{Block Diagramm des Atmega 32u4~\cite[][4]{atmel2016}}
\label{fig:block-diag-32u4}
\end{figure}
-Verwendung fand in diesem Projekt eine Arduino-kompatible Platine (siehe \ref{fig:leonardo-olimex}) des bulgarischen
+Verwendung fand in diesem Projekt eine Arduino-kompatible Platine (siehe Abb.\ \ref{fig:leonardo-olimex}) des bulgarischen
Herstellers Olimex\footnote{\url{https://www.olimex.com/Products/Duino/AVR/OLIMEXINO-32U4/open-source-hardware}},
welche gegenüber dem offiziellen Arduino Leonardo einige Vorteile sowie ein
besseres Preis-Leistungs-Verhältnis bietet.
-\begin{figure}[hb]
+\begin{figure}[h]
\centering
\includegraphics[width=0.42\textwidth]{graphics/leonardo-olimex.jpg}
\caption{Arduino Leonardo kompatibler OLIMEXINO-32U4 -- Quelle: Olimex}
@@ -271,15 +255,33 @@ besseres Preis-Leistungs-Verhältnis bietet.
\end{figure}
\section{Quadrocopter}
-\begin{figure}[hb]
+Als Quadrocopter wird im Allgemeinen ein Fluggerät bezeichnet, welches über vier
+starr am Rahmen befestigte, drehbar gelagerte Rotoren verfügt.
+Angetrieben werden diese Rotoren jeweils durch einen Elektromotor. Die Drehzahl dieser
+Motoren und der meist direkt mit diesen gekoppelten Rotoren kann mittels sog.\ Fahrtregler
+gestellt werden. Hierdurch ist eine Steuerung des durch die einzelnen Rotoren generierten
+Auftriebs möglich.
+
+Eine individuelle Steuerung der Rotorgeschwindigkeiten ermöglicht ein Neigen des
+Quadrocopters um seine Roll- und Nick-Achse und somit eine Fortbewegung in der Horizontalebene.
+Durch kollektive Drehzahländerungen aller Rotoren kann die Vertikalgeschwindigkeit
+des Quadrokopters beeinflusst werden. Für weitergehende Informationen bzgl.\ der
+Funktionsweise eines Quadrokopters kann der entsprechende Eintrag in der Wikipedia
+herangezogen werden \cite{wikipedia1}.
+
+Die Regelung der Lage und Geschwindigkeit eines Quadrocopters erfolgt mittels einer
+Flugsteuerung an Bord. Diese stellt ein für sich eigenständiges eingebettetes System
+dar, welches über entsprechende Sensorik zur Lage- und ggf.\ Positionserkennung verfügt.
+
+Die Steuerung eines Quadrocopters durch den Piloten erfolgt bspw.\ konventionell
+mittels einer Funkfernsteuerung oder auch per App über ein Mobiltelefon.
+
+\begin{figure}[h]
\centering
\includegraphics[width=\textwidth]{../../common/header.jpg}
\caption{Der in diesem Projekt verwendete Quadrocopter}
\label{fig:quad-sexy}
\end{figure}
-- funktionsprinzip
-- steuerung
-- flugcontroller
\chapter{Anforderungen}
Die gegenwärtige Aufgabe des RC-Mischers ist die Signalaggregation,
@@ -312,7 +314,7 @@ Systems zu vernetzen:
Neben diesen funktional-bedingten Anforderungen gilt es insbesondere zwei sicherheitskritische
Anforderungen umzusetzen:
\begin{itemize}
- \item{Echtzeitfähigkeit im Sinne der Rechtzeitigkeit: Signalwiederholungsraten
+ \item{Harte Echtzeitfähigkeit: Signalwiederholungsraten
von mindestens 50Hz -- daraus resultierend Zykluszeiten kleiner 20ms.}
\item{Operative Sicherheit: Ein manuelles Eingreifen muss zu jedem Zeitpunkt möglich
sein. Darüber hinaus muss ein Deakivieren des Mischer-Verhaltens im Flugbetrieb möglich sein.}
@@ -337,7 +339,7 @@ PlatformIO ist eine plattformübergreifende Enwicklungsumgebung, welche auf dem
Atom-Texteditor\footnote{Atom Texteditor - \url{https://atom.io/}} aufsetzt und diesen neben zahlreichen Funktionen
um mehrere Toolchains zur Entwicklung auf eingebetteten Systemen ergänzt.
Derzeit unterstützt werden folgende Plattformen (Auswahl): Atmel AVR \& SAM, Espressif, Freescale Kinetis,
-ST STM32, TI MSP430 \& Tiva, Teensy, Arduino, mbed u.a. (vgl. \cite[][]{platformio}).
+ST STM32, TI MSP430 \& Tiva, Teensy, Arduino, mbed u.\,a.\ (vgl.\ \cite[][]{platformio}).
Konkret Verwendung findet in diesem Projekt die Arduino- und Atmel-AVR-Unterstützung.
So greifen wir beispielsweise für die serielle Kommunikation zwischen den einzelnen
Hardware-Komponenten auf Arduino-Bibliotheken zurück. Das Arduino-Frame"=work basiert
@@ -348,7 +350,7 @@ mit, wenn man es mittels des Atom-eigenen Paketverwalters installiert und den At
als Zielplattform auswählt.
Atom stellt darüber hinaus einen sehr mächtigen Texteditor für zahlreiche Betriebssysteme
dar, und lässt sich um Funktionen wie einen PDF-Betrachter und LaTeX-Unterstützung
-erweitern (siehe Abbildung \ref{fig:atom-platformIO}).
+erweitern (siehe Abb.\ \ref{fig:atom-platformIO}).
\begin{figure}[hbt]
\centering
\includegraphics[width=\textwidth]{graphics/atom-platformio.JPG}
@@ -366,7 +368,7 @@ board = leonardo
framework = arduino
\end{lstlisting}
Um ein Projekt in PlatformIO zu importieren, muss lediglich das Projekt-Stammverzeichnis
-der Tree-View in Atom hinzugefügt werden (siehe \ref{fig:add-project}).
+der Tree-View in Atom hinzugefügt werden (siehe Abb.\ \ref{fig:add-project}).
\begin{figure}[hb]
\centering
\includegraphics[width=0.5\textwidth]{graphics/add-project.jpg}
@@ -381,7 +383,7 @@ Bedingt durch die Wahl eines Arduinos als Zielplattform erfolgte die Umsetzung
der Taskverwaltung in Form einer Bibliothek. Maßgeblich war dabei eine möglichst
einfache Verwendung dieser, damit der Nutzer sich auf sein Hauptprojekt fokussieren
kann, ohne sich zunächst in den Scheduler einarbeiten zu müssen. Weiterhin sollten
-die Tasks für den Nutzer frei konfigurierbar (d.h. beliebige Kombinationen von
+die Tasks für den Nutzer frei konfigurierbar (d.\,h.\ beliebige Kombinationen von
Echtzeit- und Nicht-Echtzeit-Tasks) sein, um ein möglichst breites
Anwendungsspektrum zu ermöglichen.
@@ -398,7 +400,7 @@ erachtet. Der vollständige Quellcode findet sich im Anhang.
Die Bibliothek \lstinline{Scheduler.h} deklariert die Funktionen und globalen
Variablen der Implementation der Taskverwaltung.
Mittels der Schlüsselwörter \lstinline{public} und \lstinline{private} kann an dieser
-Stelle die Schnittstelle zum Nutzer festgelegt werden; d.h. es kann definiert
+Stelle die Schnittstelle zum Nutzer festgelegt werden; d.\,h.\ es kann definiert
werden, auf welche Elemente von außerhalb (ohne Überschreiben) zugegriffen werden
kann und auf welche nicht. Weiterhin werden in der Bibliothek die verwendeten
Datenstrukturen und Threshold-Werte definiert.
@@ -429,15 +431,17 @@ Initialisierung zugewiesen werden kann und einem Zeitstempel, in dem seine letzt
Ausführungszeit gespeichert wird. Es ist dabei zu beachten, dass lediglich
Funktionen ohne Übergabeparameter und Rückgabe-Werte zulässig sind, da der
Scheduler eine reine Taskverwaltung und keine datenverarbeitende Instanz darstellt.
+Der Datenaustausch zwischen den Tasks ist mittels globaler Variablen wie bspw.\
+dem \lstinline{rcSource}-Struct realisiert.
Die Datenstrukturen \lstinline{rtTask} und \lstinline{nRtTask} erben beide direkt von
\lstinline{task} mit dem einzigen Unterschied, dass Realtime-Tasks eine Zykluszeit
und Non-Realtime-Tasks eine Ausführungs-Priorität zugewiesen bekommen.
Die Vererbung ermöglicht es, Funktionen, die von der Art des Tasks unabhängig sind,
-lediglich einmal für beide Typen zu definieren (vgl. beispielsweise \lstinline{sortTasks}).
+lediglich einmal für beide Typen zu definieren (vgl.\ beispielsweise \lstinline{sortTasks}).
Weiterhin ergibt sich durch die grundsätzlich gleiche Datenstruktur von \lstinline{rtTask}
und \lstinline{nRtTask} die Möglichkeit, äquivalent auf die Attribute \lstinline{cycleTime}
-und \lstinline{priority} zuzugreifen (d.h. über die Funktion \lstinline{getTaskCycleTime}
+und \lstinline{priority} zuzugreifen (d.\,h.\ über die Funktion \lstinline{getTaskCycleTime}
kann auf einen Non-Realtime-Task dessen Priorität erhalten werden).
Die Datenstruktur \lstinline{linkedListElement} stellt einzelne Elemente einer
@@ -445,7 +449,7 @@ verknüpften Liste bereit. Diese enthalten jeweils einen Pointer auf einen Task
(und sind damit zunächst unabhängig davon, ob es sich um einen Realtime- oder
einen Non-Realtime-Task handelt) und einen Pointer auf das nächste Listenelement.
Die durch die Verknüpfung der Elemtente entstehende Liste ist unidirektional,
-d.h. sie kann nur von vorne nach hinten, nicht jedoch andersherum durchlaufen werden.
+d.\,h.\ sie kann nur von vorne nach hinten, nicht jedoch andersherum durchlaufen werden.
\begin{lstlisting}[caption=Festlegen der Threshold-Werte]
#define MAX_TASK_THRESHOLD 10
@@ -455,7 +459,7 @@ d.h. sie kann nur von vorne nach hinten, nicht jedoch andersherum durchlaufen we
\end{lstlisting}
Über die Threshold-Werte können verschiedene Eigenschaften der Taskverwaltung
beeinflusst werden. Mittels \lstinline{MAX_TASK_THRESHOLD} lässt sich die maximal
-zulässige Anzahl an Re"=altime- und Non-Realtime-Taks (jeweils) festlegen, um einer
+zulässige Anzahl an Realtime- und Non-Realtime-Taks (jeweils) festlegen, um einer
Überlast vorzubeugen und sicherzustellen zu können, dass das übergebene Task-Array
korrekterweise mit einer \lstinline{NULL} beendet wird.
@@ -477,9 +481,8 @@ Während in der Bibliothek \lstinline{Scheduler.h} grundlegende Datenstrukturen,
die Funktionsnamen inklusive Übergabe- und Rückgabe-Parametern und die
Nutzer-Schnittstelle mittels \lstinline{public} und \lstinline{private} definiert wurden,
folgt in der Datei \lstinline{Scheduler.cpp} die konkrete Implementierung der Funktionen.
-Allgemein wurde dabei vor allem Wert auf auf eine möglichst effiziente Ausführung,
-um eine möglichst gute Echtzeitfähigkeit zu erreichen und Mikrokontroller-Konformität,
-um diesen nicht zu überlasten, gelegt.
+Das Hauptaugenmerk lag hierbei auf einer effizienten Ausführung, um Echtzeitfähigkeit
+mit den begrenzten Ressourcen eines Mikrocontrollers zu realisieren.
\begin{lstlisting}[caption=Konstruktor]
// Constructor with task-array as input-argument
@@ -504,7 +507,7 @@ Nicht-Echtzeit-Tasks verwaltet werden, oder sollen die Arrays eigenständig mitt
der Funktionen \lstinline{setRtTasks(...)} und \lstinline{setNRtTasks(...)} gesetzt werden,
so kann dies durch die Übergabe eines Nullpointers an der entsprechend anderen
Stelle beim Konstruktoraufruf signalisiert werden. Standardmäßig werden alle in
-der Bibliothek deklarierten, pointerargiten Elemente mit \lstinline{NULL} initialisert;
+der Bibliothek deklarierten, pointerartigen Elemente mit \lstinline{NULL} initialisert;
alle (Zahlen-)Counter werden auf den Wert null gesetzt. Anschließend werden die
Funktionen \lstinline{setRtTasks(...)} und \lstinline{setNRtTasks(...)} aufgerufen.
@@ -542,7 +545,7 @@ auf Non-Real"=time-Task vor und weist es der Programmintern verwendeten
Variable \lstinline{nRtTasks} zu. Zunächst werden die Tasks in dem Array gezählt.
Wie bereits erwähnt, muss das übergebene Array am Ende einen Nullpointer enthalten,
um das Ende zu kennzeichnen. Überschreitet die Anzahl der Tasks den für
-\lstinline{MAX_TASK_THRESHOLD} festgelegten Wert (s. Kapitel \ref{Scheduler.cpp}),
+\lstinline{MAX_TASK_THRESHOLD} festgelegten Wert (siehe Kapitel \ref{Scheduler.cpp}),
so gibt die Funktion, falls ein serieller Debugging-Port mittels \lstinline{setDebugger(...)}
übergeben wurde, eine Fehlermeldung aus und der Scheduler schaltet sich mittels
\lstinline{exterminate()} ab (bzw. konkret wechselt er in eine Dauerschleife).
@@ -591,7 +594,7 @@ dieser Stelle einmalig nach den Zykluszeiten der Realtime-Tasks und nicht nach
den Prioritäten sortiert wird. Dadurch wird erreicht, dass die Tasks in der Reihenfolge
der Zeitpunkte, wann sie das erste Mal ausgeführt werden müssen, stehen.
Anschließend wird das Array mittels \lstinline{convertToLinkedList(...)} in eine
-verknüpfte Liste umgewandelt, da es sich in diesem Datenformat einfacher gestaltet,
+einfach verkettete Liste umgewandelt, da es sich in diesem Datenformat simpler gestaltet,
die Echtzeit-Tasks nach ihrer Ausführung an die Stelle ihrer nächsten Ausführungszeit
in der Warteschlange einzusortieren.
@@ -602,7 +605,7 @@ in der Warteschlange einzusortieren.
// first, right the last position in the array to be sorted
void Scheduler::sortTasks(task **tasks, int left, int right) {
if (left < right && (right-left+1) > 1 && tasks && *tasks) {
- // Heapsort (allways O(n*log(n)); iterative)
+ // Heapsort (always O(n*log(n)); iterative)
int length, start, heapLength, i, j;
task *reference;
@@ -643,7 +646,7 @@ void Scheduler::sortTasks(task **tasks, int left, int right) {
}
\end{lstlisting}
Bei \lstinline{sortTasks(...)} handelt es sich um einen Heapsort-Algorithmus mit der
-durchschnittlichen Ordnung von O(n*log(n)). Dieser sortiert das übergebene Array
+durchschnittlichen Ordnung von $\mathcal{O}(n\cdot\log n)$. Dieser sortiert das übergebene Array
entweder nach Zykluszeiten oder nach Prioritäten (abhängig davon, ob ein Array mit
Pointern auf Realtime- oder auf Non-Realtime-Task übergeben wurde).
Dadurch, dass als Typ des Übergabeparameters die Grund-Datenstruktur \lstinline{task}
@@ -655,11 +658,9 @@ wie bereits in Kapitel \ref{Scheduler.h} angeführt, sowohl \lstinline{rtTask} a
Der Vorteil des Heapsort-Algorithmus gegenüber dem aus Quicksort-Verfahren besteht darin,
dass ersterer iterativ abläuft, während letzterer rekursiv aufgerufen wird.
Somit wird einem Überlaufen des Stacks des Mikrokontrollers vorgebeugt.
-Weiterhin weist der Heapsort unabhängig von der initialen Reihenfolge der zu
-sortierenden Elemente eine konstante Ordnung von O(n*log(n)) auf,
-während der Quicksort diese Ordnung lediglich im Durchschnitt einhält und im
-schlechtesten Fall O(n\^2) erreicht, was ihn für die Verwendung innerhalb einer
-echtzeitkritischen Applikation weniger geeignet macht.
+Die bereits erwähnte Ordnung des Heapsorts ist darüber hinaus unabhängig vom Inhalt
+des zu sortierenden Arrays, sie ist konstant. Sein Verhalten ist folglich deterministisch,
+weswegen er sich für die gegebene echtzeitkritische Anwendung anbietet.
\\
\\
Anmerkung: Für die Herleitung und Grundlagen des Heapsort-Algorithmus vergleiche
@@ -691,13 +692,13 @@ linkedListElement * Scheduler::convertToLinkedList (task **tasks)
}
\end{lstlisting}
Mittels \lstinline{convertToLinkedList(...)} wird das übergebene Array mit Pointern
-auf Tasks in eine verknüpfte Liste umgewandelt und der Zeiger auf das erste Element
+auf Tasks in eine einfach verkettete Liste umgewandelt und der Zeiger auf das erste Element
der Liste zurückgegeben. Grundsätzlich ist die Implementierung der Funktion unabhängig davon,
ob Realtime- oder Non-Realtime-Tasks übergeben werden; konkret werden jedoch lediglich
die Echtzeit-Tasks in Listenform verwaltet, da sich durch den Zugriffsalgorithmus an
dieser Stelle Zeiteinsparungen erzielen lassen, während sich die Effizienz bei
Nicht-Echtzeit-Tasks gegenüber der Array-Speicherform verschlechtern würde
-(Quicksort ist besser für Arrays als für verknüpfte Listen geeignet).
+(Quicksort ist besser für Arrays als für einfach verkettete Listen geeignet).
Zunächst wird mit \lstinline{new_pointer} ein Zeiger auf ein mittels der Funktion
\lstinline{newLinkedList-}
@@ -840,27 +841,16 @@ bildet das Herzstück der Taskverwaltung. Grundsätzlich werden drei möglich F
\lstinline{NULL}). In diesem Fall ruft der Scheduler die Funktion \lstinline{perform()} auf,
die für die Verwaltung der Nicht-Echtzeit-Tasks zuständig ist.}
\item{Es sind Realtime-Tasks vorhanden. In diesem Fall überprüft der Scheduler zunächst,
- ob die Differenz zwischen dem letzten Ausführungszeitpunkt des im ersten Element von
- \lstinline{rtTasks} gespeicherten Task (der bedingt durch die Sortierung der als nächste
- Auszuführende ist) und der aktuellen Systemlaufzeit die vorgesehene Zykluszeit des Tasks
- überschreitet. Falls nicht wird für den Fall, dass ebenfalls zu verwaltende
- Non-Realtime-Tasks vorhanden sind, \lstinline{perform()} aufgerufen.
- Überschreitet die Differenz die Zykluszeit, so wird weiterhin geprüft,
- ob die Differenz zwischen theoretisch vorgesehenem und praktischem Ausführungszeitpunkt
- außerhalb des mittels \lstinline{OVERLOAD_THRESHOLD_}
- \lstinline{PERCENT} festgelegten prozentualen
- Thresholds liegt und gegebenenfalls der Overload-Counter hochgezählt.
- Überschreitet \lstinline{overloadCounter} die in \lstinline{OVERLOAD_THRESHOLD_TIMES}
- definierte Grenze, so schaltet sich die Taskverwaltung mittels \lstinline{exterminate()} ab,
- da aufgrund von Überlast keine ausreichende Echtzeitfähigkeit mehr gewährleistet werden kann.
+ ob innerhalb des aktuellen Zyklus noch Zeit für die Ausführung von Non-Realtime-Tasks ist.
+ Hierzu wird die vorraussichtliche Ausführungszeit des nächsten Realitme-Tasks
+ mit der verbleibenden Zykluszeit verglichen. Ist noch Zeit übrig und sind Non-Realtime-Tasks
+ vorhanden, so wird \lstinline{perform()} aufgerufen.
Ansonsten wird der Realtime-Task abgearbeitet, sein Timestamp wird aktualisiert
und er wird abhängig von seinem nächsten vorgesehenen Ausführungszeitpunkt mittels
- \lstinline{sortRtTasks(...)} in die verknüpfte Liste der Echtzeit-Tasks einsortiert.
+ \lstinline{sortRtTasks(...)} in die einfach verkettete Liste der Echtzeit-Tasks einsortiert.
Existieren weiterhin zu verwaltende Non-Realtime-Tasks, so wird abschließend die
Funktion \lstinline{setPriorities()} aufgerufen, um gegebenenfalls mittels dynamischer
- Prioritätenvergabe Starvation (d.h. dass ein Non-Realtime-Task niemals ausgeführt wird,
- weil die höherpriorisierten Tasks bereits die gesamte verfügbare Zeit zwischen
- den Echtzeit-Tasks in Anspruch nehmen) zu verhindern sowie der Zeiger auf den
+ Prioritätenvergabe Starvation zu verhindern. Abschließend wird der Zeiger auf den
aktuellen Nicht-Echtzeit-Task zurückgesetzt.}
\end{itemize}
@@ -941,19 +931,15 @@ ein möglichst allgemein gehaltenes Mischer-Framework, welches im Modellbau
übliche Signalen aus unterschiedlichsten Quellen verarbeiten und mischen kann.
\subsection{Implementierung der Inputs und Outputs}
-Bevor man ein Gemisch erzeugen kann, braucht man zunächst einmal Einzelkomponenten
-aus welchen sich das Gemisch zusammensetzen soll. Dies gilt nicht nur für farbige
-Schokolinsen oder alkoholische Getränke, sonder auch für Daten jeder Form.
-Nun soll der hier vorgestellte Mischer mit Daten von unterschiedlichen Funk-Fernsteuerungen
+Der hier vorgestellte Mischer soll mit Daten von unterschiedlichen Funk-Fernsteuerungen
aus dem Modellbau-Bereich umgehen können.
Wie in den Grundlagen bereits dargestellt, hat sich im Modellbau ein Wertebereich
von 1000µs-2000µs Pulsweite für die Ansteuerung von Servo-Motoren und Drehzahlstellern etabliert.
-Obwohl dieser Wertebereich, wie im folgenden noch näher erläutert werden soll, für
-das Mischen von Daten aus mehreren Quellen nicht ideal ist, wurde sich aus Gründen
-der Kompatibilität zu etablierten Komponenten, für eine Beibehaltung und konsequente
-Verwendung dieses Wertebereiches entschieden. So tauschen die einzelnen Software-Komponenten
-die Kanaldaten in Form eines Structs aus. Dieses bietet Speicherplatz für bis zu
-16 Kanäle sowie einen Zeitstempel zur Ermittlung der Aktualiät der gespeicherten Daten.
+Obwohl dieser Wertebereich für das Mischen von Daten aus mehreren Quellen nicht ideal ist,
+wurde sich aus Gründen der Kompatibilität zu etablierten Komponenten, für eine Beibehaltung
+und konsequente Verwendung dieses Wertebereiches entschieden.
+Die einzelnen Software-Komponenten tauschen die Kanaldaten über globale Variablen in Form eines Structs aus.
+Dieses bietet Speicherplatz für bis zu 16 Kanäle sowie einen Zeitstempel zur Ermittlung der Aktualiät der gespeicherten Daten.
Der Datentyp des data[]-Arrays wurde gemäß dem abbzubildenden Wertebereich von 1000-2000
als uint16 gewählt.
@@ -1022,17 +1008,17 @@ void Mixer::mix()
_out->timestamp = micros();
}
\end{lstlisting}
-Die Verarbeitung bzw. Vermischung der eingehenden Daten findet in der Funktion mix() statt.
+Die Verarbeitung bzw. Vermischung der eingehenden Daten findet in der Funktion \lstinline{mix()} statt.
Sicherheit im Sinne von Wahrung der manuellen Kontrolle über das System zu jedem
Zeitpunkt ist hier das Hauptaugenmerk. So befindet sich der Mischer zunächst in
-einem inaktiven Zustand, in welchem er lediglich die an in0 vorliegenden Daten in
-out kopiert. in0 stellt hierbei die von der Fernsteuerung empfangengen Daten dar.
-Erst wenn ein frei definierbarer Kanal der in0 Quelle, also der Fernsteuerung mit
+einem inaktiven Zustand, in welchem er lediglich die an \lstinline{in0} vorliegenden Daten in
+out kopiert. \lstinline{in0} stellt hierbei die von der Fernsteuerung empfangengen Daten dar.
+Erst wenn ein frei definierbarer Kanal der \lstinline{in0} Quelle, also der Fernsteuerung mit
welcher das Fluggerät manuell geflogen wird, einen ebenso frei definierbaren Wert
-überschreitet, werden die Daten aus der Sekundär-Quelle in1 mit den Daten aus der
-Primär-Quelle in0 gemischt.
+überschreitet, werden die Daten aus der Sekundär-Quelle \lstinline{in1} mit den Daten aus der
+Primär-Quelle \lstinline{in0} gemischt.
In der oben dargestellten Implementierung ist die Gewichtung der Sekundärquelle über
-den Wert ebendieses frei definierbaren Kanales in einem Bereich von 10\% - 100\% einstellbar.
+den Wert ebendieses frei definierbaren Kanales in einem Bereich von 10\% -- 100\% einstellbar.
Die untere Grenze von 10\% ergibt sich hier aus der Verwendung eines einzelnen Kanales
sowohl für die Aktivierung des Mischers als auch für die Wahl der Gewichtung. So
ist der Mischer hier erst ab einem Wert von 1100 aktiv, dies entspricht 10\% Gewichtung.
@@ -1111,7 +1097,7 @@ Die Methode \lstinline{getData()} formatiert diese Daten und kopiert sie in das
der Klasse übergebene rcSource Objekt.
Die Android-Applikation sendet zwei Datenkanäle, konkret die Position des erkannten
-Kreises in der x-y-Ebene. x und y sind hierbei positive Ganzzahlen im Bereich von 0-255,
+Kreises in der $x$-$y$-Ebene. $x$ und $y$ sind hierbei positive Ganzzahlen im Bereich von 0--255,
mit 128 gleichbedeutend der Mitte des Erfassungsbereiches. Eine Übertragung der Werte
als uint8 in Form eines einzelnen Bytes pro Kanal ist folglich naheliegend und
wurde auch dementsprechend implementiert.
@@ -1157,9 +1143,9 @@ Somit ist es nötig, Daten von einer handelsüblichen Funkfernsteuerung zu empfa
und dem Mischer zur Verfügung zu stellen.
Die Wahl des verwendeten Funkempfängers fiel aus mehreren Gründen auf einen kompakten
-und leichten Spektrum-kompatiblen Empfänger, einen sog. Satelliten-Empfänger oder Remote-Empfänger.
-Ausschlaggebend für diese Wahl war die Bereitstellung einer Implemen"=tierungs-Anleitung
-von Seiten Spektrums bzw. Horizon Hobbys (vgl. \cite[][]{spek2016}). Darüber hinaus
+und leichten Spektrum-kompatiblen Empfänger, einen sog.\ Satelliten-Empfänger.
+Ausschlaggebend für diese Wahl war die Bereitstellung einer Implementierungs-Anleitung
+von Seiten Spektrums bzw. Horizon Hobbys (vgl.\ \cite[][]{spek2016}). Darüber hinaus
findet das Spektrum DSMX Protokoll im europäischen und amerikanischen Raum große
Verbreitung und es stehen zahlreiche kompatible und preisgünstige Fernsteuerungen
zur Verfügung, welche dieses Protokoll unterstützen. Dies unterstützt das Ziel dieser
@@ -1202,9 +1188,9 @@ mittels einer einfachen seriellen Schnittstelle gemäß der untenstehenden Spezi
upon the selected protocol. The packet is transmitted at 125000bps, 8 bits, No parity, 1 stop (8N1).
For those UARTs which are not capable of that speed, they will also work at the more-standard
115200bps.
-(vgl. \cite[][2]{spek2016})
+(vgl.\ \cite[][2]{spek2016})
\end{quote}Die Formatierung dieser empfangenen Daten unterscheidet sich grundlegend von dem
-simplen Protokoll welches im vorrangegangenen Abschnitt vorgestellt wurde.
+simplen Protokoll, welches im vorrangegangenen Abschnitt vorgestellt wurde.
Sie ist ausführlich in dem von Horizon Hobby, LLC herausgegebenen Dokument beschrieben:
\begin{quote}
[...][T]he first two bytes (fieldname “fades” in Section 8.4 below) indicate the fade
@@ -1213,7 +1199,7 @@ Sie ist ausführlich in dem von Horizon Hobby, LLC herausgegebenen Dokument besc
use 2048.
All data fields are big-endian, that is, the MSB is transmitted before the LSB. Bit 0 is the lsb, bit 15
is the msb.
- (vgl. \cite[][3,4]{spek2016})
+ (vgl.\ \cite[][3,4]{spek2016})
\end{quote}
\begin{lstlisting}[caption=Spektrum::dataReceive()]
void Spektrum::dataReceive()
@@ -1246,7 +1232,7 @@ Bits 15 & Servo Phase \\
Bits 14-11 & Channel ID \\
Bits 10-0 & Servo Position \\
\end{tabular}\\
-(vgl. \cite[][4]{spek2016})
+(vgl.\ \cite[][4]{spek2016})
\end{quote}
Analog zu der bereits vorgestellten Klasse \lstinline{RawSerial} bietet auch
\lstinline{Spektrum} eine \lstinline{getData} Methode, welche analog ihrem bereits
@@ -1268,7 +1254,7 @@ Kompatibilität mit Software wie MultiWii und Cleanflight stellt sich das MSP al
ideales Protokoll zum Datenaustausch zwischen Mischer und Flugsteuerung dar.
Da es zu dem MSP keine zusammenhängende Dokumentation gibt und der entsprechende
-Eintrag in dem MultiWii-Wiki (vgl. \cite[][]{multiWii2015}) lediglich eine Übersicht
+Eintrag in dem MultiWii-Wiki (vgl.\ \cite[][]{multiWii2015}) lediglich eine Übersicht
über die verfügbaren Datenfelder bietet, wurde an dieser Stelle auf die Umsetzung
des MSP in Cleanflight zurückgegriffen, um sich anhand dieser ein Verständnis der
Funktionsweise der Datenübertragung mittels MSP zu erarbeiten.
@@ -1321,7 +1307,7 @@ crc & = XOR of <size>, <command> and each data byte into a zero'ed sum \\
Die Implementierung dieses Protokolls gestaltet sich als verhältnismäßig einfach,
die folgende Methode \lstinline{SerialEncode()} ist speziell und ausschließlich
für das Bilden und Senden sogenannter \glqq{}MSP\_SET\_RAW\_RC\grqq{}-Pakete
-(message\_id = 200, vgl. \cite[][]{multiWii2015}) geschrieben.
+(message\_id = 200, vgl.\ \cite[][]{multiWii2015}) geschrieben.
\pagebreak
\begin{lstlisting}[caption=MultiWiiSerial::SerialEncode()]
@@ -1401,9 +1387,8 @@ Das Senden der Daten an die Flugsteuerung ist echtzeit-kritisch und erfolgt mit
einer vorgegebenen Zykluszeit von 20ms.
\section{Testbedingungen}
-Getestet wurde zum einen auf einem Labortisch, zum anderen auf der im Rahmen des
-Schwesterprojektes VBLS genutzten Flugplattform, einem Quadrocopter in X-Anordung.
-Die Hauptdiagonale zwischen zwei Rotoren beträgt 415mm, der Rotordurchmesser beträgt 210mm.
+Getestet wurde der Mischer auf der im Rahmen des Schwesterprojektes VBLS genutzten
+Flugplattform, einem Quadrocopter in X-Anordung.
In Abbildung \ref{fig:pic-quad-detail-sexy} gut zu erkennen ist der schichtweise Aufbau des
Testaufbaus:
@@ -1423,6 +1408,8 @@ dem Mischer und insbesondere dem Scheduler das gewünschte Verhalten.
Nach einem Dauertest über den Zeitraum von 45 Minuten konnte kein Verklemmen oder
unerwünschtes Verhalten festgestellt werden.
+\todo{Harte Fakten! Zykluszeiten ermitteln und dokumentieren.}
+
Im Verlaufe der abschließenden Flugversuche ist kein einziger Ausfall zu vermerken,
welcher auf das in diesem Projekt geschaffene System zurückzuführen wäre.
Dies bedeutet, dass der Mischer die gesetzten Anforderungen bezüglich der Echtzeitfähigkeit
@@ -1439,7 +1426,8 @@ einzelnen Methoden auf kooperatives Multitasking zuzuschreiben.
\begin{figure}[hbt]
\centering
\includegraphics[width=0.75\textwidth, trim= 0cm 2cm 0cm 1cm, clip]{../../common/photos/Quad-web-4.jpg}
- \caption{Draufsicht auf die Oberseite des Versuchsaufbaus}
+ \caption{Draufsicht auf die Oberseite des Versuchsaufbaus.
+ Die Hauptdiagonale zwischen zwei Rotoren beträgt 415mm.}
\label{fig:pic-quad-top}
\vspace{\baselineskip}
\includegraphics[width=0.75\textwidth, trim= 0cm 1.5cm 0cm 0cm, clip]{../../common/photos/Quad-web-5.jpg}
@@ -1448,14 +1436,19 @@ einzelnen Methoden auf kooperatives Multitasking zuzuschreiben.
\end{figure}
\chapter{Zusammenfassung}
+\section{Inhaltliches Fazit}
Abschließend lässt sich festhalten, dass alle Projektziele und -anforderungen
erfüllt werden konnten.
-Nicht nur konnte eine Vernetzung der Einzelkomponenten RC-Emp"=fänger, Mobiltelefon
+Nicht nur konnte eine Vernetzung der Einzelkomponenten RC-Empfänger, Mobiltelefon
und Flugsteuerung hergestellt und im Testbetrieb aufrecht erhalten werden, diese
konnte sich auch in mehreren Testflügen über einen Zeitraum von insgesamt mehr als
60 Minuten bewähren.
-Die Entwicklung dieses Systems hat uns als Autoren der hierführ nötigen Software
+\section{Persönliches Fazit}
+Ergänzend zu dem vorangegangenen inhaltlichen Fazit möchten wir zum Ende dieser
+Dokumentation noch kurz unser persönliches Fazit ziehen.
+
+Die Entwicklung dieses Systems hat uns als Autoren der hierfür nötigen Software
und dieser Dokumentation einiges an Zeit gekostet. Zusammenfassend lässt sich jedoch
sagen, dass diese Zeit ausgesprochen sinnvoll investiert ist und die gewonnenen
Erkenntnisse und Erfahrungen den nötigen Aufwand mehr als rechtfertigen. Auch konnten
@@ -1471,16 +1464,14 @@ lädt jedoch zu Erweiterungen und Modifikationen ein:
\begin{itemize}
\item{Erweiterung um weitere Protokolle}
\item{Erweiterung des eigentlichen Mischer-Codes, beispielsweise um eine Möglichkeit
-der Parametrisierung zur Laufzeit, etwa mittels eines CLI -- Kommandozeileninterfaces --
-denkbar wäre hier auch eine Konfiguration des Mischers über eine Android-Applikation,
+der Parametrisierung zur Laufzeit, etwa mittels eines Kommandozeileninterfaces.
+Denkbar wäre hier auch eine Konfiguration des Mischers über eine Android-Applikation,
ganz im Sinne des Schwesterprojektes VBLS}
\item{Portierung auf andere Plattformen, beispielsweise den ESP8266. Dieses SoC
-- System on Chip -- stellt neben mehr Prozessor- und Speicherkapazitäten noch
WLAN zur Verfügung, worüber eine GUI zur Konfiguration des Mischers oder Telemetriedaten
bereitgestellt werden können.}
\item{Integration in andere Plattformen, beispielsweise MultiWii oder Cleanflight.}
-\item{Miniaturisierung des Aufbaus, entweder durch Integration in andere Plattformen,
-oder durch Verwendung kleinerer Platinen.}
\end{itemize}
\printbibliography[heading = bib]