Quelltext der Seite KOM: RS232-Kommunikation DS1104-Karte mit PC

'''Betreuer: '''Prof. Dr.-Ing [[Benutzer:Ulrich Schneider|Ulrich Schneider]] <br>
'''Autor:''' [[Benutzer:David_Weigt|David Weigt]], [[Benutzer:Louis_Holtaple|Louis Holtaple]](WiSe 23/24) <br>
=Einleitung=
Der Artikel behandelt die Kommunikation zwischen der DS1104-Karte und den PC via RS232-Schnittstelle. Dabei versendet der PC die Aufgenommenen Kameradaten an die dSPACE-Karte. Diese wiederum sendet einen Lenkwinkel und eine Längsgeschwindigkeit zurück. Eine C++ Software sowie ein entsprechendes Simulink Modell für den Test der RS232-Kommunikation sind bereits vorhanden. Der Test ergab, dass eine Fehlerfreie Kommunikation nur unter Nutztung einer sehr geringen Übertragungsrate oder unter Nutztung eines für den Anwendungszweck überdimensionierten Pufferspeichers möglich ist (siehe Abschnitt „Ist-Analyse“). Das gesetzte Ziel liegt darin eine Fehlerfreie Kommunikation unter Verwendung eines passenden Puffers von 256 Bytes und der angestrebten Übertragungsrate von 115200 Baut zu erreichen. Zwecks der Genauigkeit sollen dabei auch die Datentypen der Übertragenen Signale bestehen bleiben.

= Ist-Stand 23/24 RS232-Kommunkikation =
Der Aktuelle Zustand zum Begin des Praktikum ist es, dass die Kommunikation nicht fehlerfrei lauffähig ist. Diese Problematik ist daher ein Knackpunkt für die Lauffähigkeit des Fahrzeugs. Aus diesem Grund ist, wie in ''Sprint 1'' ausführlich analysiert und beschrieben, die Lauffähigkeit Prio eins dieses Teams. 
 
== Aufbau der Kommunikation ==
[[Datei:Schema_Konzept_SDE_CCF_Kommunikation.PNG|thumb|right|600px|Abb. 1: Schema des Kommunikations-Konzepts nach Schnittstellen Dokumentation (Regelkreis mit dSPACE-Karte stark vereinfacht) ]]
Der Aufbau der Kommunikation ist in ''Abbildung 1'' dargestellt. Zunächst werden die aufgenommenen Daten vom LiDaR und der Kamera an den PC weitergeleitet. Durch eine Software, in C und C++ geschrieben, wird die Objekt- und Spurerkennung (OSE), sowie das Versenden der OSE-Daten, über die RS232 Schnittstelle realisiert. Über ein 9 poliges Sub-D Kabel werden die Daten der OSE an die dSPACE-Karte übermittelt. Die Daten der OSE werden dann in die Berechnung der Bahn- und Spurführung einbezogen. Zur Berechnung der OSE-Daten soll in Zukunft die dSPACE-Karte den Lenkwinkel und die Geschwindigkeit an den PC zurück senden. Eine genauere Beschreibung des Kommunikationskonzeptes und der seriellen Schnittstelle findet sich unter folgendem Artikel: [https://wiki.hshl.de/wiki/index.php/Kom_-_Kommunikation Kommunikation Wintersemester 2022/23]
Durch ein Testprogramm können Dummy-Parameter der OSE über die RS232 Schnittstelle an eine baugleiche dSPACE-Karte gesendet werden. Auf der dSPACE-Karte ist ein Simulink-Testmodell des Datenaustauschs der dSPACE-Karte geladen, worüber das Empfangen der OSE-Daten im ControlDesk sichtbar gemacht werden kann. In den fogleden zwei Abschnitten soll nun die etwas detaillierter auf die Kommunikation beider Seiten eingegangen werden, damit das Grundkonzept und der grobe Aufbau der Software klar ist. 
<br/>








=== Code Aufbau auf '''PC''' ===
----
Der eigentliche Code für die Übertragung auf die dSPACE Karte beinhaltet einen Aufbau über mehrere Bibliotheken. So sind im Testmodell des Trunks im Ordner der Spurpolynom Software folgende Einbindungen zu finden.
<syntaxhighlight lang="cpp">
//RS232 Kommunikation
#include "parameter.h"  //Zuvor all_needed.h
#include "RS232Comm.h"

#include "rs232.h"
#include "Connect.h"
</syntaxhighlight>
Diese sollen einen einfachen Umgang mit der RS232 Schnittstelle gewährleisten. So sind Objekte mit den entsprechenden Membern und Variablen im Vorfeld programmiert. 
Einen einfache Initialisierung der Schnittstellen Datentypen und die Nutzung der Member für die Definition der RS232 Kommunikationseigenschaften, ist im folgenden Code Ausschnitt einmal dargestellt.
<syntaxhighlight lang="cpp">
RS232Comm OSE_comPort_st(COMPORT, BAUDRATE, "8N1", 0); //Festlegen des Comports, der Bautrate und weiteren Einstellungen 
msg_to_pc OSE_msg_p(); //Datenstruktur für Daten die von der dSpace Karte an den PC gesendet werden
msg_to_dspace OSE_msg_d(); //Datenstruktur für Daten die vom PC an die dSpace Karte gesendet werden
// OSE_comPort_st.RS232_SetComPort(0, 115200, "8N1", 0); wird in dem neuen Code über den Konstruktor eingerichtet
OSE_comPort_st.RS232_OpenComPort(); //Startet eine Verbindung ohne Handshake 
</syntaxhighlight>

Nachdem sowohl die Strukturen angelegt sind, als auch die COM-Schnittstelle. Sollte bei dem Aufbau zu der Seriellen Schnittstelle etwas fehlgeschlagen sein, wird der Anwender direkt dazu informiert.
Im späteren Verlauf der Anwendung kommt es dann zu dem Punkt, dass Daten empfangen oder versendet werden sollen. Dazu werden die hier folgenden Member (''Funktionen einer Klasse'') verwendet.
<syntaxhighlight lang="cpp">
OSE_comPort_st.RS232_SendDataBigEndianFirst(OSE_msg_d);//Senden von Daten
OSE_comPort_st.RS232_PollFunction(OSE_msg_p);//Empfangen von Daten
</syntaxhighlight>
Wichtig ist,''' sollten Änderungen an den zu versendeten Datentypen gemacht werden, so müssen auch die Member der Klasse angepasst werden''', damit es nicht zu undefinierten Verhalten kommt.
Damit der COM-Treiber am Ende der Ausführung für andere Programme wieder freigeben wird, kann am Ende folgende Funktion aufgerufen werden bzw. wird bei dem Destruktor ein Verbindungsabbruch erzwingt.
<syntaxhighlight lang="cpp">
OSE_comPort_st.RS232_CloseComPort(); //Schließen der COM-Port Verbindung 
</syntaxhighlight>
<br/>

=== Simulink Model auf '''dSPACE Karte''' ===
----
<br/><br/>


<br/><br/><br/>
----
= <div align="center" style="font-size:150%;">Sprint 1</div> =

== Zielsetzung ==
Ziel soll es sein, mit der Bautrate von 115200 und dem für den Anwendungsfall ausreichendem Pufferspeicher, eine lückenlose Kommunikation herzustellen. Dazu sollen beide Kommunikation Teilnehmer eine sichere Datenübertragung gewährleisten, sodass unabhängig von Datenrate und -menge, keine Daten verloren gehen oder willkürliche Werte annehmen. Dazu muss eine schnelle und ausführliche Erprobung erfolgen, damit kausale Zusammenhänge genau verstanden werden können. Eine detailliertes Verständnis ermöglicht häufig die Vermeidung weiterer Fehler und kann das volle Potenzial der seriellen Übermittlung ausnutzen.
<br/><br/>

== Problembeschreibung ==
[[Datei:Kommunikationstest ControlDesk.png|thumb|right|400px|Abb. 2: Darstellung des Datenempfangs in ControlDesk (Regelkreis mit dSPACE-Karte stark vereinfacht) ]]
Beim Test der Kommunikation mit dem Testmodell ergaben sich bei gegebener Übertragungsrate von 115200 Baut Unterbrechungen bei der Übertragung der Dummy-Parameter. ''Abbildung 2'' zeigt die Darstellung der übertragenen Spurparameter A, B und C im ControlDesk. Dabei ist festzustellen, dass jeweils alle drei Werte zu bestimmten Zeiten auf andere Werte springen. Das bedeutet, dass bei der Übertragung der 
Spurparameter fehlerhafte Werte ankommen oder falsch interpretiert werden. Im vorherigen Semester wurde bereits ein Test mit erhöhtem Pufferspeicher der dSPACE-Karte durchgeführt. Bei vierfacher Puffergröße konnte bis auf wenige Ausreißer eine Lückenlose Übertragung realisiert werden. Die Maximierung der Puffergröße ist jedoch für den Anwendungsfall zu groß dimensioniert. Desweiteren wurde bereits mit einer kleineren Bautrate experimentiert. Die Bautraten für eine Lückenlose Übertragung waren jedoch zu gering, um eine Echtzeitreaktion des Systems zu gewährleisten. 
<br/><br/>

== Analyse der Ursachen ==
Damit, wie im in der Zielsetzung beschrieben, eine genaue Kausalität entsteht, wurden für die Test eine schnelle " Trail-and-Error" Methode verwendet. Dazu wurden der [https://svn.hshl.de/svn/MTR_SDE_Praktikum/branches/2023_OSE_Spurerkennung_Sprint_3/ Branch: 2023_OSE_Spurerkennung_Sprint_3] verwendet. Dieser beinhaltet wie auch der Trunk, einen [https://svn.hshl.de/svn/MTR_SDE_Praktikum/branches/2023_OSE_Spurerkennung_Sprint_3/Testmodell_Kommunikation/ComTest Test Ordner (ComTest)] welcher ein einfaches Testmodell beinhaltet. Dieses kann für die Übertragung von Dummy-Werten genutzt werden. <br/>



[[Datei:Setup UART Bearbeitet.png|thumb|right|Abb 3: Setzen des RTS/CTS Flag in Simulink]]
== Fehlerbehebung == 
=== Fehlender Handshake bei der Datenübertragung ===
Für die Kommunikation zwischen zwei RS232 Teilnehmern können spezielle Flags verwendet werden, welche die Gegenseite die Empfangs- und Sendebereitschaft symbolisieren. Eine genauere Beschreibung bietet hierbei folgender Artikel [https://de.wikipedia.org/wiki/RS-232#Verkabelung_und_Stecker Link]; zudem ist auf ''Abbildung 3'' zu sehen, wo genau dieses Flag in Simulink aktiviert wurde. In diesem ist zu sehen, dass sogenannte CTS Flags der Gegenseite die Empfangsbereitschaft signalisieren. So kann sichergestellt werden, dass die Empfangsseite auch wirklich die Daten verarbeiten kann. Eine solche Abfrage kann leicht über die DSpace Karte eingestellt werden. Die Senderseite, also der C++ Code, muss dafür sorgen, dass diese Flags erkannt und nur bei Bestätigung die Daten gesendet werden. Dazu wurden die Folgenden Befehle dem Code hinzugefügt. <br>
<syntaxhighlight lang="cpp">
// Dient der Abfrage der Empfangsbereitschaft 
while (!RS232_IsCTSEnabled(comPortNumber_u16)) {}
</syntaxhighlight>
[[Datei:Setup Fifo Simulink.png|thumb|right|Abb 5: Richtige Einstellung für FIFO Speicher]]










=== Fehlerfafte Löschung des FIFO Speichers ===
[[Datei:Fehlerhafte löschung des FIFOs.MP4|thumb|left|Abb 4: Beispiel Animation wie der Speicher fehlerhaft ausgelesen und gelöscht wird]]
Bei Überlauf des FIFO-Puffers der dSPACE-Karte müssen die alten Daten aus dem Puffer gelöscht werden. Bei der Löschung ist es essentiell, dass die gelöschte Datenmenge der Größe des Datenpakets, welches mit einem Übertragungszyklus gesendet werden entspricht, so wie auf ''Abbilung 5'' zu erkennen ist. Andernfalls werden Datenpakete teilweise gelöscht und somit unvollständig am Ausgang des FIFO-Puffers angelegt. In ''Abbildung 4'' ist dazu eine Animation zu sehen, welche diese Problematik darstellen soll.




















----
=<div align="center" style="font-size:150%;">Sprint 2</div>=

==Zielsetzung==
Für diesen Sprint war es das Ziel eine Rücksendung via dSPACE Karte zu schaffen ('''Rücksendung''') und Performance- sowie Sicherheitsaspekte genauer zu untersuchen. So ist es wichtig bei einer C/C++ Applikation richtige Schritte einzuleiten, um unverzeihbare Fehler oder Ausfälle zu vermeiden. Außerdem ist die erste Aufgabe, dass gesamte Modell auf dem Fahrzeug zum Laufen zu bringen. Dies ist erst der Fall, wenn der oben beschriebene Fehler beseitigt wurde. Dies unterliegt der höchsten Priorität, da sonst weitere Team keine Messungen am Fahrzeug durchführen können. ('''Com-Port Verbindung scheitert''') 

==Com-Port Verbindung scheitert==

===Problembeschreibung===
----
[[Datei:Problem Comport Verbindung Programmfenster.png|thumb|500px|right| Abb 4: Terminal hängt sich beim Start der Kommunikation auf]]
Bei dem Übergang auf von ''Sprint 1'' zu ''Sprint 2'' sind weitere Punkte aus dem vorherigen Sprint übernommen worden. Dazu zählte die Paarung mit dem Programm des [https://wiki.hshl.de/wiki/index.php/OSE:_Bildverarbeitung_mit_Spurerkennung OSE Teams], welches für die Bildverarbeitung zuständig ist. Dabei ist es zu einem Ausfall der Exe Seitens der Kommunikation gekommen. Ein Beispiel hierfür ist auf ''Abbildung 4'' zu sehen. Der Code wird in diesem Fall bei dem Verbindungsaufbau unterbrochen, sodass sich das Programm nicht mehr ausführen lässt.






===Analyse der Ursachen===
----
Für die erste Beurteilung möglicher Ursachen wurde der [https://svn.hshl.de/svn/MTR_SDE_Praktikum/trunk/_Semesterordner/WS2023/Sprint_2/KOM_RS232/A3_Report_Sprint2_KOM_Com-Port_Verbindung_scheitert.xlsx A3 Report Com-Port Verbindung scheitert] zur Hilfe genommen. Bei dieser sind für die drei Hauptursache folgende Gründe eingetragen worden:
{| class="wikitable"
|-
! Com-Port in der Exe falsch gesetz für <br>Verwendung am Fahrzeug !! Programmablauf der Exe fehlerhaft !! Com-Port defekt
|-
| OSE-Spurparemeter.exe gibt Fehler bei  <br> Verindungsaufbau aus|| Programmablauf bleibt im Acknowledgement <br> hängen || Verbindung zum Mainboard unterbrochen
|-
| Com-Port im Programm auf 0 als <br> Standardwert gesetzt|| Dauerschleife beim Abfragen des <br> Acknowledgement || Kalte Lötstelle
|-
| Com-Port 0 existiert am PC des Fahrzeuges <br> nicht, Kamera auf Com-Port 1 oder 2 <br> angeschlossen|| Abfrage der Falgs ist Fehlerhaft || Interne Kabelbrüche
|-
| || || Abgebrochne Pins
|}

Nach einer genaueren Beurteilung wurde dann für das Problem die Dauerschleife bei der Abfrage des CTS Flags als Fehlerursache festgestellt. Weitere Versuchen ergaben zudem, dass die dSPACE Karte für die erste Verwendung der C++ Software gestartet werden muss bzw. Control Desk diese in den Zustand online versetzten sollte. Damit ist sichergestellt, dass das aktuelle und richtige Modell geladen ist, zudem wird die Karte erst in diesem Schritt einsatzbereit. Seitens der C++ Software ist zu erkennen, dass wie der folgende Code auschnitt zeigt, es einer Verbesserung des Codes bedarf, damit es zu keinem Deadlock kommt.
<syntaxhighlight lang="cpp">
// Dient der Abfrage der Empfangsbereitschaft 
while (!RS232_IsCTSEnabled(comPortNumber_u16)) {} //Erzeugt bei dem nicht Empfangen des CTS Flags einen Deadlock
</syntaxhighlight>

===Fehlerbehebung===
----
[[Datei:Messung Kom RS232 Spurparameter mit Referenz.jpg|thumb|right|600px| Abb 5: Gegenüberstellung von Empfangs- und Sendeseite]]
Die Maßnahmen der Fehlerbehebungen waren in diesem Fall teilweise komplexer umzusetzen. Aus diesem Grund sollte die elegantere Lösung einer Fehlerausnahmebehandlung zu einem späteren Zeitpunkt eingebunden werden. Die letztlich temporäre leichtere Lösung ist es, zu kontrollieren, dass die dSPACE Karte vor jeder Verwendung aktiviert und mit dem richtigen Modell geladen wurde. Nach diesen Prinzip ergibt sich kein Fehlerbild bei der Ausführung. Trotzdem sollte eine Ausnahmebehandlung in den bestehenden Code eingebaut werden, damit auch Simulationen ohne dSPACE Karte erfolgen können. Ein Nachweis der Wirksamkeit wurde im Anschluss an die behobene Fehlerquelle erzielt, indem die Empfangs- und Sendeseite aufgezeichnet und gegenüber gestellt wurden. Dies ist auf ''Abbildung 5 '' genauer zu erkennen.



















==Rücksendung==
Damit Daten seitens des PCs in das bestehende Open CV Modell zur Berechnung mit einbezogen werden können, ist es notwendig, gemessene Daten von der dSPACE-Karte zurück zu den PC zu senden. Diese sind auch unter dem Artikel [https://wiki.hshl.de/wiki/index.php/Kom_-_Kommunikation#Überblick_Variablen| Kom - Kommunikation ] zu finden. Dabei handelt sich um die Ego-Längsgeschwindigkeit und den Lenkwinkel des Fahrzeugs. Eingebunden wird diese Struktur über <syntaxhighlight inline lang="cpp"> #include <parameter.h> </syntaxhighlight> . 
<syntaxhighlight lang="cpp">
typedef struct
{
	double V_x_ego;
	double alpha;
}msg_to_pc;
</syntaxhighlight>

===Umsetzung===
----
Bei der Umsetzung wurde der schon vorhandene Member <syntaxhighlight inline lang="cpp"> OSE_comPort_st.RS232_PollFunction(OSE_msg_p);</syntaxhighlight> verwendet. Dazu wurde der Funktionsrumpf so angepasst, dass er den Anforderungen der RS232 Übertragung entspricht. Die dabei aufgetretenen Fehler sind in einem weiteren [https://svn.hshl.de/svn/MTR_SDE_Praktikum/trunk/_Semesterordner/WS2023/Sprint_2/KOM_RS232/A3_Report_Sprint2_KOM_Rücksendung.xlsx A3 Report] aufgefasst worden und sollen anschließend erläutert werden.

====Simulink Model auf '''dSPACE Karte''' ====
Damit eine Übertagung möglich gemacht werden kann benötigt man eine Funktion, welche die Datentypen in einen unsigned char zerlegt. Die in dem Empfangsblock verwendete S-Funktion eignet sich hierbei weniger, da die Performance und Modularität darunter leiden. Aus diesem Grund wurde eine sogenannte Bytepack Funktion verwendet, welche extra von Simulink für diese Übertragungen bereitgestellt wurde.
Folgende ''Abbildung 6'' zeigt diesen Übertragungsblock. <syntaxhighlight inline lang="matlab"> Send_Data</syntaxhighlight> beinhaltet die zuvor gemuxten double Werte, welche übertragen werden sollen. Über den Block ''Unpack'' werden dann die Datentypen in einen unsigned char array verpackt, welches über den Muxer das Startzeichen ''89'' an den Anfang gestellt bekommt. Über die Konstante ''17'' wird zudem die versendete Byte Menge angeben.
[[Datei:Sende_Block_im_Sub.png|thumb|center|600px|Abb 6: Übertragungsblock der dSPACE-Karte]]

====Code Aufbau auf '''PC'''====
Bei dem C++ Code wurde zu Begin die schon vorhandene Funktion ausgeführt, welche ein Rücksenden ermöglichen sollte. Allerdings war diese Fehlerbehaftet; diese sollen im nächsten Abschnitt beschrieben. 
Im Folgenden ist nun der C++ Code zu sehen, welcher finalisiert funktioniert und nach der Fehlerbehandlung umgesetzt wurde. Die hierbei angefügten Kommentare beschreiben dabei den gesamten Programmablauf, weshalb darauf nicht genauer eingegangen wird.
<syntaxhighlight lang="cpp">
// Auf Daten im Empfangsbuffer warten
int RS232Comm::RS232_PollFunction(msg_to_pc& msg)
{
	
	static std::array<unsigned char, RX_BYTES> receiveByte_u8;  //Speichersicheres C++ Array
	static int requestResponse_16{ 0 }; //Anzahl der Empfangenen Daten in Byte
	
		// Wenn der Debug-Modus läuft wird der Infotext ausgegeben
		
		//Abfrage nach dem Startbyte
		if(requestResponse_16 < 1){
			for (size_t i{ 0 }; i < RX_BYTES; i++) {
				RS232_PollComport(COMPORT, &*(receiveByte_u8.begin()), 1);
				if (receiveByte_u8.at(0) == DS_START_BYTE)
					break;
				if (i == 15)
					return -1;
			}

		}
		RS232_disableDTR(COMPORT);
		//Dynamisches Lesen des Pufferspeichers falls nicht alle 16 Byte enthalten
		requestResponse_16 += RS232_PollComport(COMPORT, &*(receiveByte_u8.begin()+requestResponse_16), 16-requestResponse_16);
		
		//Ausnahmebedingungen schaffen
		if(!requestResponse_16){
			cerr << "Keine Werte Lesbar\n";
			return -1;
		}
		else if (requestResponse_16<0) {
			cerr << "Keinen Speicherzugriff\n";
			return -1;
		}
		else if (requestResponse_16 < RX_BYTES) {
			return 0;
		}

#ifdef _DEBUG
		cout << "Empfangene Daten\n";
#endif

		//Setzt Bytezähler und Buffer zurück
		requestResponse_16 = 0;
		RS232_flushRX(COMPORT);

		//Empfangsbereit
		RS232_enableDTR(COMPORT);
		// Kehre Endian-Folge um
		HF_SwitchEndianness(receiveByte_u8, RX_BYTES);

		//Erstelle Struktur aus den Datenx
		HF_UcharArrayToStruct(receiveByte_u8.data(), (void*)&msg, sizeof(msg_to_pc));

#ifdef _DEBUG
		cout << "alpha: " << msg.alpha << "\n";
		cout << "V: " << msg.V_x_ego << endl;
#endif

	
	// Thread schließen. Wird noch nicht ausgeführt.
	return 0;
}
</syntaxhighlight>

===Problembeschreibung===
----
{| class="wikitable" style="float:right;"
! Vorher !! Nachher
|- 
| [[Datei:Falsche Ausgabe.png|thumb|right|200px| Abb 7: Ausgabe von falschen Werten]] || [[Datei:Richtige Ausgabe.png|thumb|right|200px|Abb 8: Empfangene Daten entsprechen den gesendeten Konstanten 12 & 13]] 
|- 
|}
Bei der ersten Ausführung des Code sind Fehler aufgetreten, die zu einem undefinierten Verhalten geführt haben. Dabei wurden Daten aus dem Puffer aufgelesen, die den gesendeten Konstanten nicht entsprechen. So ist auf ''Abbildung 7'' zu erkennen, dass die Kostanten 12 und 13 zeitweise abweichen.





===Analyse der Ursachen===
----
Zu den Uhrsachen konnten nur wenige Punkte benannt werden, diese relativ eindeutig war. Trotzdem wurde hierzu ein A3 Report erstellt der bei den drei Hauptuhrsachen zu folgenden Ergebnis gekommen ist.
{| class="wikitable"
|-
! Fehlendes Startbyte für korrektes Auslesen <br> des Pufferspeichers!! Empfangsprogramm liest falsche <br> Datenmenge aus dem Puffer!! Auslesealgorithmus der Rücksendedaten <br> fehlerhaft
|-
| Startbyte makiert den Anfang des <br> Datenpakets|| dSpace-Karte sendet zusätzliche Daten || Fehlerhaftes wechseln von Big- zu Little-Endian
|-
| Empfangsseite muss wissen wann ein  <br> vollständiges Datenpaket im Puffer anliegt|| Gesendete Datenmenge stimmt nicht mit <br> der Datenmenge überein die aus dem Puffer <br> ausgelesen wird || Datentypen werden in der falschen Reihenfolge <br> aufgelöst
|-
| Startbyte könnte von Datentypen ausgelöst <br> werden  || Datenstrom wird nicht am Anfang und Ende <br> sondern mittendrin zerlegt || Übergabe auf den Struct ist fehlerhaft
|-
| Startbyte wird nicht richtig interpretiert || Andere Programme nutzten den COM <br> Speicher  || Daten werden nicht konstant gespeichert 
|-
| || ||Löschen des Pufferspeichers ist zu früh
|}


===Fehlerbehebung===
----
Erste Erfolge wurden bei kleineren Test erzielt. Allerdings sind diese Ergebnisse noch nicht zu manifestieren, da es sich hierbei nicht um einen kontrollierten Test gehandelt hat. <br>Trotzdem sind die Ergebnisse vielversprechenden. So ist auf ''Abbildung 8'' eine eindeutig konstante Übertragung der Werte zu erkennen.




----
=<div align="center" style="font-size:150%;">Sprint 3</div>= 

== Zielsetzung ==
Während der Praxisphasen wurden nun also einige der essenziellen Probleme gelöst. So läuft jetzt die Übertragung einwandfrei. Des Weiteren ist es nun möglich Daten seitens der dSPACE Karte zurück zu senden. Diese Implementierung
soll nun am Fahrzeug intrigiert werden. Zudem gibt es weiter Probleme was die Verbindung mit der dSPACE Karte angeht. So kann es durch den C++ Code zu einem Deadlock kommen, wenn die Karte nicht erreichbar ist. Auch dieses Problem soll beseitigt werden. Ein weiteres Ziel ist es, dass [https://wiki.hshl.de/wiki/index.php/BSF:_Bahnregelung_quer Querregelungs Team] zu unterstützen, damit das Fahrzeug zum Ende fahrtüchtig ist.


== Rücksendung ==


===Umsetzung===
Da es keine Rolle zu dem aktuellen Zeitpunkt spielt, ob die Rücksendung funktioniert, wurde nur eine Instanz in dem C++ Code zum Laufen gebracht. Diese wurde in das trunk Modell eingepflegt und getestet.
So ist es nun möglich über die dSPACE Karte zwei entscheidende Werte zum PC zurück zu versenden. 

===Fehlerbehebung===
Während der Erprobungen der Bilderkennung Exe sind im Lauf der Zeit Fehler bei der Programmierung aufgefallen. So kann die Querregelung keine vernünftigen Werte Berechnen, wenn Seitens der Bildverarbeitungen NaN Werte in den Spurparametern stehen und sollte es zu keiner Kommunikation zwischen PC und dSPACE Karte kommen, wird diese dauerhaft beendet. Damit diese Fehler keine Auswirkungen mehr auf die Regelung des Fahrzeugs haben, sollen diese beseitig oder teilweise behoben werden.

==== NaN Werte filtern ====
Damit eine Filterung ermöglicht werden kann, müssen nur die Zustände der einzelnen Parameter abgefragt werden. Dazu wurde die in C++ intrigierte Funktion <syntaxhighlight lang="css" inline>isnan()</syntaxhighlight> verwendet. Diese Werte werden dann durch default Werte ersetzt, damit diese ggf. erkannt werden können oder nicht zum auslenken des Fahrzeugs führen.<br>
'''parameter.h'''
<syntaxhighlight lang="css">
constexpr double false_a{ 0 };
constexpr double false_b{ 0 };
constexpr double false_c{ 0.0007 };
</syntaxhighlight> 
'''RS232Comm.cpp'''
<syntaxhighlight lang="css">
case 0:	//Spurparamenter a
	if (isnan(msg->lp.a)) {
		msg->lp.a = false_a;
	}
	bytePointer_u8 = (unsigned char*)&msg->lp.a; //Zugriff auf Byte eines Floats
	counterBytes_u8 = 4;
	break;

case 1:	//Spurparamenter b
	if (isnan(msg->lp.b)) {
		msg->lp.b = false_b;
	}
	bytePointer_u8 = (unsigned char*)&msg->lp.b; //Zugriff auf Byte eines Floats
	counterBytes_u8 = 4;
	
	break;

case 2:	//Spurparamenter c
	if (isnan(msg->lp.c)) {
		msg->lp.c = false_c;
	}
	bytePointer_u8 = (unsigned char*)&msg->lp.c; //Zugriff auf Byte eines Floats
	counterBytes_u8 = 4;
	
	break;
</syntaxhighlight>

==== dSPACE Karte erkennen ====
Ein weiterer Fehler, der sich auf die Stabilität des System ausgewirkt hat, war die Erkennung der dSPACE Karte. Dabei wurde geschaut, ob die Karte online ist oder nicht, damit die Abfrage des CTS-Flags nicht in einem Deadlock endet. Damit dieser Fehler nicht mehr auftritt, wurde dem Code eine Watchdog hinzugefügt, die die Deadline für eine Abfrage des Flags festlegt. Der dazu gehörige Code ist im nachfolgenden Ausschnitt zu sehen. <br>
'''parameter.h'''
<syntaxhighlight lang="css">
constexpr int TIMEOUT{ 1000 };
</syntaxhighlight> 
'''RS232Comm.cpp'''
<syntaxhighlight lang="css">
static bool send = true;
</syntaxhighlight> 
...
<syntaxhighlight lang="css">
if (send) {			// Abfrage ob die dSPACE Karte online ist 
	while (!RS232_IsCTSEnabled(comPortNumber_u16)) {
		TimeInTic = clock() - Time_Start;
		Time = (double)TimeInTic / (CLOCKS_PER_SEC / 1000);
		if (Time > TIMEOUT) {
			cout << "dSPACE Karte nicht online\n";
			Sleep(200);
			send = 0;
			return 0; }
	} //Warten auf Sendeerlaubnis
}
else {

	if (!send && RS232_IsCTSEnabled(comPortNumber_u16)) { //Frage ob dSPACE Karte online, wenn "ja" Senden wieder aufnehmen
		send = true;
	}
	else {
		return 0;
	}
}

</syntaxhighlight>
==Querregelung==
Damit das Gesamtkonzept Fahrzeug am Ende funktioniert, hat sich unser Team der Querregelung angeeignet. Diese hatte zum Ende keine Möglichkeit die Spur zu verfolgen und musste daher für die weitere Fahrt verbessert werden.

===Problembeschreibung===
Bei einer gerade Fahrt geradeaus und in einer Kurve, kam es dazu, dass das Fahrzeug nach einer gewissen Zeit von der Fahrbahn abkam. Dies hatte zur Folge, dass nur eine gewisse Zeit das Fahrzeug fahrtüchtig war. Kleinere Abweichungen der Spur konnte zum totalen auslenken des Fahrzeugs führen. Darüber hinaus konnten somit keine Einparkversuche stattfinden, da auch hier das Fahrzeug auf die Querregelung angewiesen war.

===Analyse der Ursachen===
Bei der Messung der Geradeausfahrt ist war zu erkennen, dass nach kleineren Abweichungen der Spur zum Auslenken des Fahrzeugs führen. Somit kann nur ein zu hoher Anteil der PID Werte der Auslöser dafür sein, da diese zum Aufschwingen der Regler Werte führen.


===Fehlerbehebung===
[[Datei:PID-Regler.png|thumb|right|600px|Abb : PID-Regler Werte und Spurparameter]]
Um eine saubere Fahrt zu ermöglichen mussten dazu die PID Anteile angepasst werden. Da die Anteile viel zu große Werte aufweisen, müssen diese minimiert werden. Dazu wurde der P-Anteil und der D-Anteil um Faktor 10 reduziert. 
Die sich draus ableitenden Ergebnisse sind auf ''Abb'' zu erkennen. Das Fahrzeug schafft es bis zum Kurven Eintritt einen saubere Regelung zu vollziehen. Erst in der Kurve, wenn die Bilderkennung große Schwankungen erzeugt, kommt es zum Ausfall der Querreglung und somit zum ablenken des Fahrzeugs.






















= <div align="center" style="font-size:125%;">'''Ausblick für kommende Semester'''</div> = 

== Rücksendung ==

== Querregelung == 



= Inbetriebnahme =
* [[Sensor-/Aktortest KOM]]

= Nützliche Links =
*[https://de.wikipedia.org/wiki/Hilfe:Wikisyntax#Talk_and_project_pages%7C| Wiki Syntax]
*[[AMR:_Aufbau_eines_Autonomen_Fahrzeugs|Vorarbeiten]]
*[[Kom_-_Kommunikation]]
*[[OSE_-_Objekt_-_und_Spurerkennung]]
*[[RS232_Bibliothek]]

= Mögliche Software =
*[https://www.serial-port-monitor.org/de/rs232-sniffer/ RS232 Sniffer]
*[https://www.com-port-monitoring.com/de/ Serial Port Monitor] 
*[https://freeserialanalyzer.com/ Free Serial Analyzer]
*[http://www.serial-port-monitor.com/ Free Serial Port Monitor]

----
→ zurück zum Hauptartikel: [[Praktikum_SDE|Praktikum SDE]] | [[SDE-Team 2023/24]]