Quelltext der Seite Simulationsumgebung für die Objekt- und Spurerkennung

'''Autoren:''' Hagen Heuer, Tim Kruse, Marius Köhler, Stefan Arndt<br/>
'''Betreuer:''' [[Benutzer:Ulrich_Schneider| Prof. Schneider]]<br/>

== Einleitung ==
''' Autoren:''' Hagen Heuer, Tim Kruse<br/>
Um die Hauptnutzungszeit der Kamera für Funktionstests zu verringern, soll eine Simulationsumgebung in Visual Studio programmiert werden. Ziel ist es hierbei die Weiterverarbeitung der Bilder, welche die Kamera bereitstellt, zu implementieren und zu testen.

Es sollen hierbei folgende Funktionen der Bildverarbeitung implementiert und getestet werden.
* Erstellung eines Binärbildes, um die Rechenleistung zu optimieren
* Festlegen der Region of Interest, um die Rechenleistung weiter zu optimieren
* Filterung von Reflektionen durch den Einfall von Licht
* Transformation des Kamerabildes in Vogelperspektive, um die Objekt- und Spurerkennung zu vereinfachen

== Anforderungen==
''' Autoren:''' Hagen Heuer, Tim Kruse<br/>

Auf Basis der gestellten Anforderungen aus dem Lastenheft konnten folgende Pflichten für die Simulationsumgebung abgeleitet werden.

<gallery mode = "traditional" widths=1000px heights=230px>
File:Pflichtenheft Heuer Kruse.png|Abb. 1: Pflichtenheft
</gallery>

Um die Zusammenarbeit beider Teams zu vereinfachen wurden weitere Anforderungen an die Bildvorverarbeitung gestellt. Diese werden nachfolgend ausgelistet und erörtert. <br/>
''' Binärbild ''' <br/>
Zur vereinfachten Objekt und Spurerkennung sollte das RGB-Farbbild in ein Binärbild gewandelt werden. Dieses stellt die Farben lediglich in Schwarz und Weiß dar. Somit sollen die Fahrbahnlinien in Weiß dargestellt werden und die Umgebung in Schwarz. <br/>

''' Reflektionen filtern ''' <br/>
Zudem sollen Reflektionen nach Möglichkeit heraus gefiltert werden, da diese sonst auf Grund ihrer Helligkeit weiß dargestellt werden und somit die Objekt- und Spurerkennung beeinträchtigen können. Im Zweifelsfalls soll die Fahrspur unterbrochen werden, um Reflektionen sicher zu filtern.  <br/>

''' Region of Interest anpassen ''' <br/>
Um die benötigte Rechenleistung zu verringern, sollte zudem der gezeigte Bildausschnitt angepasst werden. Die Bedeutet, dass das Fahrzeug nicht mehr zu sehen sein soll und die Sicht in die Ferne eingeschränkt werden soll. <br/>

''' Transformartion in Vogelperspektive ''' <br/>
Desweiteren sollen die einzelnen Bilder in Vogelperspektive transformiert werden und möglichst ohne Verzerrungen dargestellt werden.

== Konzeptentwicklung ==
''' Autoren:''' Hagen Heuer, Tim Kruse<br/>
Die Programmierung der Simulationsumgebung erfolgt in Visual Studio 2019, da die bisherige Implementierung der Kamera ebenfalls in Visual Studio erfolgte. Zudem stellen die Bibliotheken von OpenCV Funktionen bereit, welche die Simulation der VRmagic Kamera vereinfachen.

Als Grundlage für die Simulation der VRmagic Kamera dient ein Video, welches die Strecke inklusive der Stopp-Kreuzungen beinhaltet. Zudem Berücksichtigt das Fahrzeug in dem Video die Anforderungen an das Verhalten an Stopp-Kreuzungen, welches der Spurerkennung zu gute kommt.

Da zwei Teams an der Simulationsumgebung arbeiten bietet es sich an, dass Programm modular aufzubauen. Die Programmstruktur ist nachfolgend erläutert.
* main.cpp
** Hauptprogramm der Simulationsumgebung
** Implementierung der Konsolenanwendung
* Frame_lesen.cpp und Frame_lesen.h
** Einlesen des Videos
** Nächsten Frame aus dem Video extrahieren
* Bildtransformation.cpp und Bildtransformation.h
** Anpassen der Region of Interest
** Graustufenbild erstellen
** Binärbild erstellen
** Reflektionen filtern
** Transformation in Vogelperspektive
*Frame_ausgeben.cpp und Frame_ausgeben.h
** Ausgabefenster öffnen
** Video ausgeben
* ConfigLesenSchreiben
** string in eine .ini Datei schreiben
** string aus einer .ini Datei lesen

== Programmablaufpläne für die Simulationsumgebung ==
''' Autoren:''' Hagen Heuer, Tim Kruse<br/>
Um die Programmierung der Simulationsumgebung zu vereinfachen, wurden ein Programmablaufplan für das Hauptprogramm entwickelt. Zudem wurden Programmablaufpläne für die benötigten Funktionen entworfen. Diese werden nachfolgend erläutert.

=== Programmablaufplan für das Hauptprogramm ===

<gallery mode = "traditional" widths=400px heights=700px>
File:Hauptprogramm OSE Teil 1.png|Abb. 2: Hauptprogramm Teil 1
File:Hauptprogramm OSE Teil 2.png|Abb. 3: Hauptprogramm Teil 2
</gallery>

Im Hauptprogramm werden zunächst alle Variablen initialisiert.
Anschließend folgt die erste while-Schleife. In der Konsole wird nun ein Text ausgegeben und auf die Eingabe durch den Benutzer gewartet.

Wurde die Simulation ausgewählt so folgt eine weitere Ausgabe in der Konsole und man wartet auf die Eingabe durch den Benutzer. Hat dieser nun Simulation starten ausgewählt, so wird zunächst die Funktion FA_InitVideo aufgerufen. Anschließend folgt einer weitere while-Schleife, in der der jeweils nächste Frame geladen und transformiert wird. Hierfür wird zunächst die Funktion FL_GetFrame aufgerufen und abgefragt, ob ein Frame vorhanden ist. Anschließend wird die Funktion BTF_imgTranf aufgerufen. Für den Fall das keine Taste für den Abbruch gedrückt wurde, wird der nächste Frame geladen. Falls doch abgebrochen wird oder aber kein Frame vorhanden ist, werden alle Ausgabefenster geschlossen und der Inhalt der Konsole gelöscht.

Wurde innerhalb der Simulation stattdessen Dateipfad ändern ausgewählt, so folgt eine weitere Ausgabe in der Konsole. Außerdem wird auf eine Eingabe in der Konsole gewartet. Anschließend wird die Funktion CLS_Stringschreiben aufgerufen um den Dateipfad zu sichern. Nun wird der Inhalt der Konsole gelöscht. Wurde Zurück ausgewählt, so wird ebenfalls der Inhalt der Konsole gelöscht. Falls die Eingabe ungültig war so wird dies in der Konsole ausgeben und anschließend der Inhalt gelöscht.

Statt der Auswahl der Simulation kann auch die extrinsische oder intrinsische Kalibrierung ausgewählt werden. Hierbei wird lediglich etwas in der Konsole ausgegeben.

Bei ungültiger Eingabe erfolgt wieder eine Textausgabe und der Inhalt wird gelöscht.

Falls das Programm beendet werden soll wird die Eingabe erneut abgefragt. Fall auch hier ja ausgewählt wird, das Programm beendet. Andernfalls erfolgt eine Textausgabe und der Inhalt wird gelöscht, oder es wird lediglich der Inhalt gelöscht.

Im Anschluss an das Inhalt löschen erfolgt ein Sprung an das Ende der while-Schleife.

<onlyinclude><div style="clear:{{{{{|safesubst:}}}#switch:{{{1}}}
| links|left = left
| rechts|right = right
| #default = both
}};"></div></onlyinclude>

=== Programmablaufpläne für die Ausgabe ===

<gallery mode = "traditional" widths=200px heights=600px>
File:FA InitVideo.png|Abb. 4: FA_InitVideo
File:FA Ausgabe.png|Abb. 5: FA_Ausgabe
</gallery>

In der Funktion FA_InitVideo werden die Ausgabefenster, welche bei Übergabe festgelegt wurden, geöffnet. In diesen Fenstern wird das später Video dargestellt. Die Funktion FA_Ausgabe gibt letztlich das Video in dem jeweiligen Ausgabefenster aus.

<onlyinclude><div style="clear:{{{{{|safesubst:}}}#switch:{{{1}}}
| links|left = left
| rechts|right = right
| #default = both
}};"></div></onlyinclude>

=== Programmablaufpläne für das Lesen ===

<gallery mode = "traditional" widths=200px heights=300px>
File:load.png|Abb. 6: load
File:FL GetFrame.png|Abb. 7: FL_GetFrame
</gallery>

In der Funktion load wird zunächst der Dateipfad mit Hilfe der Funktion CLS_StringLesen eingelesen. Anschließend wird das Video geladen. Für den Fall, dass das Einlesen nicht erfolgreich war, wird ein Text ausgegeben und die Transformation abgebrochen. <br/>
In der Funktion FL_GetFrame werden zunächst die Variablen initialisiert. Falls noch kein Video geladen wurde, wird zunächst die Funktion load aufgerufen. Anschließend wird der nächste Frame des Videos geladen und in eine Matrix geschrieben. Falls der Frame nicht geladen werden konnte, erfolgt eine Textausgabe und das Programm wird beendet. 

<onlyinclude><div style="clear:{{{{{|safesubst:}}}#switch:{{{1}}}
| links|left = left
| rechts|right = right
| #default = both
}};"></div></onlyinclude>

=== Programmablaufpläne für die Bildtransformation ===

<gallery mode = "traditional" widths=250px heights=500px>
File:BTF ImgTransf.png|Abb. 8: BTF_ImgTransf
File:RegionOfInterest.png|Abb. 9: regionOfInterest
File:Binarisierung.png|Abb. 10: binarisierung
File:ImageTransformation.png|Abb. 11: imageTransformation
</gallery>

Die eigentliche Bildtransformation fällt im Gegensatz zu den anderen Modulen etwas größer aus.

Die Funktion BTF_ImgTransf wird aus dem Hauptprogramm aufgerufen und regelt die Transformation in Vogelperspektive. Zu Beginn wird abgefragt, ob ein RGB-Farbvideo ausgegeben werden soll. Falls ja erfolgt die Ausgabe des Videos. Anschließend wird die Funktion regionOfInterest aufgerufen, in der der Bildausschnitt angepasst wird. Anschließend wird die Funktion binarisierung aufgerufen, um ein Schwarz-Weiß Bild zu erhalten. Im letzen Schritt erfolgt die eigentliche Transformation in Vogelperspektive mit Hilfe der Funktion imageTransformation.

Mit Hilfe der Funktion regionOfInterest wir zunächst der Dargestellte Bereich des Bildes angepasst. Hierbei wird sowohl das Fahrzeug aus dem Bild geschnitten, sowie der obere Teil des Bildes verkleinert. Hierfür werden als erstes Variablen initialisiert. Anschließend wird das Bild zugeschnitten. Im letzten Schritt erfolgt die Abfrage, ob das Video ausgegeben werden soll, sowie der Funktionsaufruf FA_Ausgabe.

Mit der Funktion binarisierung wird aus dem RGB-Bild ein Binärbild erstellt. Dieses ist ein Schwarz-Weiß Bild. OpenCV bietet hierfür keine direkte Funktion an, weswegen zunächst ein Graustufenbild erstellt wird. Danach erfolgt die Abfrage, ob das Graustufenbild ausgegeben werden soll inklusive dem Funktionsaufruf FA_Ausgabe. Anschließend werden Parameter für die Binarisierung mit Hilfe der Funktionen CLS_DoubleLesen und CLS_IntLesen eingelesen. Nun kann aus dem Graustufenbild das eigentliche Binärbild erstellt werden. Auch hier folgt die Abfrage, ob das Video ausgegeben werden soll.

Im letzten Schritt wird das Binärbild mit der Funktion imageTransformation in die Vogelperspektive transformiert. Hierfür werden zunächst die Variablen initialisiert. Anschließend werden die Source- und Destination-Punkte festgelegt. Danach wird die Transformationsmatrix erstellt und im letzten Schritt die Transformation durchgeführt. Anschließend erfolgt wieder die Abfrage, ob das Video ausgegeben werden soll.

Die Funktion imageTransformation führt nun die Transformation des Binärbildes in Vogelperspektive durch. Hierfür werden zunächst Variablen initialisiert. Nun werden die Source und Destination Punkt festgelegt und die Transformationsmatrix erstellt. Nun wird die Transformation in Vogelperspektive durchgeführt. Abschließend erfolgt die Abfrage, ob das Video ausgegeben werden soll mit dem Funktionsaufruf FA_Ausgabe.

<onlyinclude><div style="clear:{{{{{|safesubst:}}}#switch:{{{1}}}
| links|left = left
| rechts|right = right
| #default = both
}};"></div></onlyinclude>

=== Programmablaufpläne um die ini-Datei lesen und zu schreiben ===

<gallery mode = "traditional" widths=150px heights=200px>
File:CLS DoubleSchreiben.png|Abb. 12: Double schreiben
File:CLS IntSchreiben.png|Abb. 13: Integer schreiben
File:CLS StringSchreiben.png|Abb. 14: String schreiben
File:CLS DoubleLesen.png|Abb. 15: Double lesen
File:CLS IntLesen.png|Abb. 16: Integer lesen
File:CLS StringLesen.png|Abb. 17: String lesen
</gallery>

Diese Sechs Programmablaufpläne dienen wie oben bereits beschrieben zum lesen und schreiben einer ini-Datei. Um in die ini-Datei schreiben zu können, muss zunächst die Information, welche gespeichert werden soll, in eine LPCSTR gewandelt werden. Anschließend kann dieser Wert gespeichert werden. Beim Lesen eines double Wertes aus der ini-Datei erhält man einen String welcher anschließend zu einem double konvertiert werden muss. Beim String lesen erhält man einen char, welcher für die weitere Verwendung in einen String formatiert wird. Nur beim lesen eines Integer ist keine Konvertierung nötig, da Integer direkt ausgelesen werden können. 

<onlyinclude><div style="clear:{{{{{|safesubst:}}}#switch:{{{1}}}
| links|left = left
| rechts|right = right
| #default = both
}};"></div></onlyinclude>

== Umsetzung und Ergebnis der Simulationsumgebung ==
''' Autoren:''' Hagen Heuer, Tim Kruse<br/>
Die Umsetzung der Simulationsumgebung erfolgte in Visual Studio 2019 Community. Für die Bild- und Videoverarbeitung wurde auf die Bibliotheken von OpenCV zurück gegriffen. Das Einbinden dieser Bibliothek ist in dem Artikel [https://wiki.hshl.de/wiki/index.php/Einrichten_von_OpenCV_in_Visual_Studio Installation von OpenCV in Visual Studio] beschrieben.

Die Implementierung erfolgt wie oben beschrieben in einzelnen Modulen, welche mehrere Funktionen beinhalten. Bei der Programmierung musste darauf geachtet werden, dass kein using namespace cv verwendet wird. Dies sorgte häufiger für Probleme. Stattdessen muss die Implementierung wie in Abbildung 18 zu sehen erfolgen und der Vorsatz cv:: verwendet werden.

[[Datei:Namespace_cv.png|none|mini|400px|Abb. 18: Verwendung von cv::]]

Das Ergebnis der Transformation ist in der Abbildung 13 zu sehen. Links ist das Original Video zu sehen und Rechts das Binärbild in Vogelperspektive. Außerdem lässt sich erkennen, dass das Fahrzeug im Binärbild nicht mehr zu sehen ist. Zudem wurde der Bildausschnitt oben verkleinert.

[[Datei:Transformation_in_VP.gif |rechts|Abb. 19: Vergleich Originalbild und Vogelperspektive]]

<onlyinclude><div style="clear:{{{{{|safesubst:}}}#switch:{{{1}}}
| links|left = left
| rechts|right = right
| #default = both
}};"></div></onlyinclude>
== Umsetzung des Live-Modus ==
Der Live-Modus wurde in den Dateien Kamera.cpp und Kamera.h implementiert und richtet sich an der Arbeit des Vorsemesters.
der Aufruf geschieht über
Kamera::connect();
Kamera::init();
in der Main-Datei

== Unit-Test ==
''' Autoren:''' Hagen Heuer, Tim Kruse<br/>
Im Folgenden sind Ergebnisse der Unit-Tests von den einzelnen Modulen zu sehen. Durch die Eingabe von Parametern konnten folgende Testfälle geprüft werden.

=== Bild ausgeben===

{| class="mw-datatable"
! style="font-weight: bold;" | ID
! style="font-weight: bold;" | Testfallbeschreibung
! style="font-weight: bold;" | Eingänge(Benötigtes Ausgabefenster, Ausgabebild)
! style="font-weight: bold;" | Ausgang(figure, ausgegebene Video) 
! style="font-weight: bold;" | Erwartetes Ergebnis
! style="font-weight: bold;" | Testergebnis
! style="font-weight: bold;" | Testperson
! style="font-weight: bold;" | Datum
|-
| 1
| Es soll kein Ausgabefenster erstellt werden und kein Video ausgegeben werden.
| Benötigtes Ausgabefenster = 0,  Ausgabebild = 0 
| Kein figure, kein Bild/Video
| Kein figure, Kein Bild/Video
| Kein Bild/Video
| Heuer, Kruse
| 16.06.2020
|-
| 2
| Ausgabefenster soll geöffnet werden, jedoch kein Bild ausgegeben werden.
| Benötigtes Ausgabefenster = RGB-Bild,  Ausgabebild = 0 
| figure RGB-Bild, kein Ausgabebild
| figure ohne Ausgabebild
| geöffnetes figure ohne Ausgabebild
| Heuer, Kruse
| 16.06.2020
|-
| 3
| Ausgabefenster soll geöffnet werden und ein Bild ausgegeben werden.
| Benötigtes Ausgabefenster = RGB-Bild,  Ausgabebild = Matrix 
| figure RGB-Bild, dargestelltes Bild
| figure mit Ausgabebild
| geöffnetes figure mit einem Ausgabebild
| Heuer, Kruse
| 16.06.2020
|}

=== Frame lesen ===

{| class="mw-datatable"
! style="font-weight: bold;" | ID
! style="font-weight: bold;" | Testfallbeschreibung
! style="font-weight: bold;" | Eingänge(Video)
! style="font-weight: bold;" | Ausgang(nächste Bild des Video) 
! style="font-weight: bold;" | Erwartetes Ergebnis
! style="font-weight: bold;" | Testergebnis
! style="font-weight: bold;" | Testperson
! style="font-weight: bold;" | Datum
|-
| 1
| Video nicht lesbar
| Video = 0
| Kein Bild
| Fehlermeldung
| Video konnte nicht geladen werden
| Heuer, Kruse
| 16.06.2020
|-
| 2
| Video vorhanden und nächste Frame verfügbar
| Video = vorhanden 
| Ausgabe des Bildes
| nächste Frame des Videos kann ausgegeben werden
| Bild ausgegeben
| Heuer, Kruse
| 16.06.2020
|-
| 3
| Letzte Frame des Videos wurde im Aufruf davor ausgegeben
| Video = 0
| kein Bild
| Fehlermeldung 
| Ausgabe von Frame konnte nicht geladen werden
| Heuer, Kruse
| 16.06.2020
|}

=== Bildtransformation ===

{| class="mw-datatable"
! style="font-weight: bold;" | ID
! style="font-weight: bold;" | Testfallbeschreibung
! style="font-weight: bold;" | Eingänge(RGB-Bild)
! style="font-weight: bold;" | Ausgang(bearbeitetes Bild) 
! style="font-weight: bold;" | Erwartetes Ergebnis
! style="font-weight: bold;" | Testergebnis
! style="font-weight: bold;" | Testperson
! style="font-weight: bold;" | Datum
|-
| 1
| Es wird kein Bild ausgegeben, wenn kein RGB-Bild vorhanden ist.
| RGB-Bild = 0
| Ausgabebild = 0
| Kein Bild
| 0
| Heuer, Kruse
| 16.06.2020
|-
| 2
| Region of Interest wird angepasst, wenn ein RGB-Bild vorhanden ist
| RGB-Bild = Matrix
| Bild Region of Interest
| Bild mit angepasster Region of Interest
| Region of Interest angepasst
| Heuer, Kruse
| 16.06.2020
|-
| 3
| RGB-Bild wird in ein Binär-Bild gewandelt
| RGB-Bild = Matrix
| Binär-Bild
| Konvertierung von RGB- zu Binär-Bild
| Binär-Bild aus RGB-Bild
| Heuer, Kruse
| 16.06.2020
|-
| 4
| RGB-Bild wird in die Vogelperspektive transformiert
| RGB-Bild = Matrix
| Bild in Vogelperspektive
| Bild mit angepasster Betrachtung
| Vogelperspektive des RGB-Bilds
| Heuer, Kruse
| 16.06.2020
|}

=== Config lesen und schreiben===

{| class="mw-datatable"
! style="font-weight: bold;" | ID
! style="font-weight: bold;" | Testfallbeschreibung
! style="font-weight: bold;" | Eingänge(Daten)
! style="font-weight: bold;" | Ausgang(Daten) 
! style="font-weight: bold;" | Erwartetes Ergebnis
! style="font-weight: bold;" | Testergebnis
! style="font-weight: bold;" | Testperson
! style="font-weight: bold;" | Datum
|-
| 1
| Daten sollen in der ini.Datei gespeichert werden
| Daten = 100 
| 100 in der ini-Datei
| Eintrag in der ini-Datei
| Wert 100 wurde in der ini-Datei eingetragen
| Heuer, Kruse
| 16.06.2020
|-
| 2
| Daten sollen aus der ini-Datei gelesen werden
| ini-Datei = 50
| Gelesener Wert = 50
| Wert aus ini-Datei gelesen
| Wert 50 wurde aus der ini-Datei gelesen
| Heuer, Kruse
| 16.06.2020
|}

== Konzept für dir Fahrspurerkennung und Approximation ==
''' Autoren:''' Stefan Arndt, Marius Köhler<br/>


[[Datei:REQ102300-Jahr2020.png|none|mini|1000px |Abb. 19: Requirements für Meilenstein 2]]


Die Requirements aus Abb. 19 werden wir folgt in ein Programmablaufplan überführt. Dabei wird grundlegend folgendes Konzept angewandt:

# Kantendetektion durchführen
# Die Spur finden und per Sliding-Window die Spur verfolgen
# Punktparameter aus den Boxen extrahieren
# Per Polyfit eine Funktion 2. Grades approximieren

Anforderungen ans Modul und Testvorgänge:

<gallery mode = "traditional" widths=250px heights=500px>
File:Fahspurpunkte berechnen.png|Abb. 20: Programmablaufplan für die Fahrspurerkennung
File:Berechne_Box.png|Abb. 21: Programmablaufplan für die Boxberechnung
</gallery>

In der Abb. 22 ist das ausgeführte Programm zu sehen. Hierbei stellen die Rechtecke die Boxen aus der Sliding-Window Methode dar.
Gelbe Boxen enthalten eine valide Linie. Rote Boxen sind nicht valide. Diese spielen bei der mittleren Linie eine große Rolle, da sie dort einen y-Offset verursachen um die unterbrochene Linienführung zu berechnen.

Die blauen Punkte die aus der approxmierten Funktion berechnet.

[[Datei:Spurerkennung_full.png|none|mini|400px| Abb. 22 Spurerkennung zum MS2]]

== Statische Codeanalyse ==

Da Polyspace nicht mehr für Stundenten kostenlos ist, wurde die statische Codeanalyse mit dem kostenlosen Tool [http://cppcheck.sourceforge.net/ cppcheck] durchgeführt.

[[Datei:OSE_Cpp_check_report.png|none|mini|1000px |Abb. 23: Bericht der statischen Codeanalyse (Stand: 15.07.2020)]]

Ergebnis: Der Bericht in Abb. 23 zeigt ausschließlich stilistische Anmerkungen. Diese sollten erst bei der Endversion überarbeitet werden, da diese zum Teil noch fürs Debuggen notwendig sind.

== Dynamische Codeanalyse ==

Die dynamische Codeanalyse wurde mit den Codeanalyse-Tools von Visual Studio 2019 durchgeführt. Einmal für die Verbrauch des Arbeitsspeicher (RAM) und der Prozessorauslastung (CPU).

[[Datei:Dyn_analyse_ram.png|none|mini|1000px |Abb. 24: Bericht der dynamischen Codeanalyse (RAM) (Stand: 15.07.2020)]]

Ergebnis: Die RAM-Auslastung ist konstant, das heißt Speicherlecks sind im Programm nicht vorhanden.

[[Datei:Dyn_analyse_cpu.png|none|mini|1000px |Abb. 25: Bericht der dynamischen Codeanalyse (CPU) (Stand: 15.07.2020)]]

Ergebnis: Auch die CPU-Auslastung ist beinahe konstant. Die größten Verbraucher der CPU-Zeit sind I/O-Funktionen und die Darstellungsfunktionen.

== Diskussion ==
''' Autoren: ''' Hagen Heuer, Tim Kruse<br/>
Binär-Bild genauer spezifizieren. Binärbild in Vogelperspektive

Äußere Schleife „Für jeden Frame“ überflüssig, da die Funktion für jeden Frame neu aufgerufen wird. (Echtzeitbetrieb) Falls noch nicht geschehen, kann der Programmablaufplan in unserem Programmablaufplan Projekt ergänzt werden. (Siehe Teamordner Heuer Kruse)

Offener Pfeil bei Abbruch. Dieser ist nicht mit dem Ende verbunden.

Reviewer: Hagen Heuer, Tim Kruse<br/>
Datum:	  17.06.2020

== Ausblick ==
''' Autoren:''' Hagen Heuer, Tim Kruse<br/>


<onlyinclude><div style="clear:{{{{{|safesubst:}}}#switch:{{{1}}}
| links|left = left
| rechts|right = right
| #default = both
}};"></div></onlyinclude>

----
Zurück zum Hauptartikel: [[OSE - Objekt - und Spurerkennung]] <br/>
→ zurück zur Übersicht: [[SDE-Team_2020/21]]<br/>