Datenübertragung zwischen PC und dSPACE Karte: Unterschied zwischen den Versionen

Version vom 26. Dezember 2020, 19:47 Uhr

Autor: Hagen Heuer und Tim Kruse
Betreuer: Prof. Dr. Mirek Göbel

Einleitung

Der folgende Artikel beschäftigt sich mit der Kommunikation zwischen dem PC und der dSPACE Karte. Die Kommunikation erfolgt hierbei mittels einer RS232-Schnittstelle. Über diese Schnittstelle wird unteranderem das Spurpolynom sowie Lidar-Daten versendet. Eine genaue Beschreibung, welche Daten übertragen werden, ist in Abbildung X zu sehen. Hier werden zudem die Datentypen genannt.
Für die Bearbeitung der Aufgabe wird zunächst der aktuelle Stand des Fahrzeugs ermittelt, da bereits eine RS232 Kommunikation besteht. Diese wird zunächst getestet. Anschließend wird die Struktur des C-Programm überarbeitet, da Funktionen des C-Programms des Vorsemesters ausgelagert werden. Im letzten Schritt soll die Datenübertragungsrate nach Möglichkeit erhöht werden und fehlende Daten übertragen werden. Diese Teilaufgabe wird durch Funktionstest abgeschlossen.

Anforderungen

Abb. 1: Lastenheft REQ10.3160

Abb. 2: Lastenheft REQ10.3275

Abb. 3: Lastenheft REQ10.3280

Abb. 4: Lastenheft REQ10.3290

Abb. 5: Pflichtenheft

Aktuelle Stand des Programms

Im ersten Schritt wurden die beiden bestehenden Ansätze im SVN betrachtet und mit einander verglichen. Ziel war es, den aktuellen Stand zu ermitteln und ein Programm auszuwählen, mit dem die Kommunikation umgesetzt wird. Die Unterschiede und Gemeinsamkeiten der beiden Programme sind in den nachfolgenden Tabelle ausgelistet.

Vergleich der beiden Programme

OSE_Fusion_Final_Software	OSE_Draufsicht_Spurpolynom_RS232	Gemeinsamkeiten
Baudrate von 19200	Baudrate von 115200
Alle Daten werden bereits übertragen	Spurparameter a,b und c werden übertragen
Daten werden aufwendig einzeln verschickt	Versand der Daten effektiv in for-Schleife gelöst
Übergabe an Funktion zum Senden gut gelöst, da Daten als struct übergeben werden	Spurparameter werden einzeln an Funktion zum Senden übergeben
Vertauschen der Byte-Ordnung aufwendig gelöst und teilweise überflüssig	Vertauschen der Byte-Ordnung durch den Einsatz von Zeigern sehr gut implementiert
		Verschachtelte Funktionsaufrufe zum Übertragen der Daten
Unter Visual Studio 2019 nicht lauffähig	Unter Visual Studio 2019 lauffähig
		Kamera bereits eingebunden
Einbindung des Lidars vorhanden	Einbindung des Lidars nicht vorhanden

Da die Einbindung des Lidars und der Kamera auf neuem Weg erfolgen soll, ist es von Vorteil das Programm vom Wintersemester 19/20 OSE_Draufsicht_Spurpolynom_RS232 zu nehmen. Zudem ist hier ein guter Ansatz für die Übertragung der Daten vorhanden, der lediglich um die weiteren Daten ergänzt werden muss. Die Aufgabe in diesem Semerster wird es sein, die Übertragung auf weitere Daten, welche in der nachfolgenden Tabelle zu sehen sind, auszuweiten. Zudem soll die Kommunikation bezüglich der Geschwindigkeit optimiert werden und eine vollständige Dokumentation der Ergebnisse erfolgen.

PC zu dSpace

Signalname	Datentyp	Beschreibung
a	float32 (4 Byte)	Fahrspurparameter
b	float32 (4 Byte)	Fahrspurparameter
c	float32 (4 Byte)	Fahrspurparameter
Spurzuordnung	bool (1 Byte)	Spurzuordnung: 1 = rechte Fahrspur, 0 = linke Fahrspur
Stopplinie erkannt	bool (1 Byte)	1 = Stopplinie erkannt, 0 = keine Stopplinie erkannt
Abstand Stopplinie	float32 (4 Byte)	Entfernung zur Stopplinie
n Objekte	uint8 (1 Byte)	Anzahl relevanter Objekte (maximal 5)
Objekt[n Objekte].Nummer	uint8 (1 Byte)	Objektzähler
Objekt[n Objekte].x0	float32 (4 Byte)	x-Koordinate des Objektmittelpunktes (mitte, vorn)
Objekt[n Objekte].y0	float32 (4 Byte)	y-Koordinate des Objektmittelpunktes (mitte, vorn)
Objekt[n Objekte].b	float32 (4 Byte)	Objektbreite
Objekt[n Objekte].t	float32 (4 Byte)	Objekttiefe
Objekt[n Objekte].alpha	float32 (4 Byte)	Objektausrichtung
Objekt[n Objekte].v	float32 (4 Byte)	Betrag des Geschwindigkeitsvektors
Objekt[n Objekte].Plausibel	uint8 (1 Byte)	Vertrauenswert für das Objekt in Prozent ( 0 = minimale Vertrauen, 100 = maximale Vertrauen)
Gesamtgröße des Datenpakets		149 Byte

Im nächsten Schritt soll nun das bestehende C-Programm getestet werden, um dem Team ein funktionsfähiges Fahrzeug bereitzustellen. Der Test der Software wurde wie in Fahrzeugkommunikation via RS232 beschrieben erfolgreich durchgeführt. Daher kann dem Team nun eine funktionierende Kommunikation mit Übertragung der Spurparameter a, b und c zur Verfügung gestellt werden.

Konzept für die Übertragung

Für die Übertragung der Daten wurden zwei Konzepte ausgearbeitet. Das erste Konzept arbeitet mit einer statischen Übertragung, bei der immer alle 149 Byte übertragen werden. Das zweite Konzept vergleicht zunächst den alten Wert der Variable mit dem neuen Wert. Wird dort ein Grenzwert überschritten, oder kommt es zu einem Flankenwechsel, so werden die Daten übertragen. Sonst wird auf die Übertragung dieser Daten verzichtet.

Abb. 2: Statische Übertragung
Abb. 3: Dynamsiche Übertragung
Abb. 4: Auswahl, welche Daten dynamisch übertragen werden

Für eine erfolgreiche Kommunikation muss zudem ein Handshake durchgeführt werden. Mit diesem wird die Verbindung zwischen PC und DSPACE-Karte getestet. Der Handshake ist hierbei in beiden Programmen gleich umgesetzt.

Abb. 3: Dynamische Übertragung

Aufgrund des fehlenden Zugriffs auf Matlab/Simulink wird nun das Konzept für die statische Übertragung umgesetzt. Hierbei muss das Matlab-Programm nicht verändert werden. Zudem ist die Implementierung der dynamischen Übertragung zeitaufwendig und schwierig, da am Ende die Regelparameter der Längs- und Querregelung angepasst werden müssen. Dies liegt daran, dass je nach Grenzwert ab dem Daten übertragen werden, die Störgröße stark abweicht und größere Sprünge macht. Dies muss durch die Regelparameter berücksichtigt und abgefedert werden. Da das Fahrzeug derzeit noch nicht fährt, wird hierfür zwangsläufig die Zeit fehlen. Es ist jedoch ein Ansatz, der von dem nachfolgenden Semester umgesetzt werden kann.

Programmierung

Die Programmierung der Kommunikation via RS232 wurde in Visual Studio umgesetzt.

Komponententest

Zusammenfassung

Link zum Quelltext in SVN

→ zurück zum Hauptartikel: SDE Praktikum Autonomes Fahren

@@ Zeile 85: / Zeile 85: @@
 ! scope="col"| Beschreibung
 |-
-! scope="row"| alpha
+! scope="row"| a
 | float32 (4 Byte)
-| Lenkwinkel des Fahrzeigs
+| Fahrspurparameter
 |-
 ! scope="row"| b
 | float32 (4 Byte)
 | Fahrspurparameter
+|-
+! scope="row"| c
+| float32 (4 Byte)
+| Fahrspurparameter
+|-
+! scope="row"| Spurzuordnung
+| bool (1 Byte)
+| Spurzuordnung: 1 = rechte Fahrspur, 0 = linke Fahrspur
+|-
+! scope="row"| Stopplinie erkannt
+| bool (1 Byte)
+| 1 = Stopplinie erkannt, 0 = keine Stopplinie erkannt
+|-
+! scope="row"| Abstand Stopplinie
+| float32 (4 Byte)
+| Entfernung zur Stopplinie
+|-
+! scope="row"| n Objekte
+| uint8 (1 Byte)
+| Anzahl relevanter Objekte (maximal 5)
+|-
+! scope="row"| Objekt[n Objekte].Nummer
+| uint8 (1 Byte)
+| Objektzähler
+|-
+! scope="row"| Objekt[n Objekte].x0
+| float32 (4 Byte)
+| x-Koordinate des Objektmittelpunktes (mitte, vorn)
+|-
+! scope="row"| Objekt[n Objekte].y0
+| float32 (4 Byte)
+| y-Koordinate des Objektmittelpunktes (mitte, vorn)
+|-
+! scope="row"| Objekt[n Objekte].b
+| float32 (4 Byte)
+| Objektbreite
+|-
+! scope="row"| Objekt[n Objekte].t
+| float32 (4 Byte)
+| Objekttiefe
+|-
+! scope="row"| Objekt[n Objekte].alpha
+| float32 (4 Byte)
+| Objektausrichtung
+|-
+! scope="row"| Objekt[n Objekte].v
+| float32 (4 Byte)
+| Betrag des Geschwindigkeitsvektors
+|-
+! scope="row"| Objekt[n Objekte].Plausibel
+| uint8 (1 Byte)
+| Vertrauenswert für das Objekt in Prozent ( 0 = minimale Vertrauen, 100 = maximale Vertrauen)
 |-
 ! scope="row" colspan="2"| Gesamtgröße des Datenpakets
-| 8 Byte
+| 149 Byte
 |}
 Im nächsten Schritt soll nun das bestehende C-Programm getestet werden, um dem Team ein funktionsfähiges Fahrzeug bereitzustellen. Der Test der Software wurde wie in [[Praktikum_SDE|Fahrzeugkommunikation via RS232]] beschrieben erfolgreich durchgeführt. Daher kann dem Team nun eine funktionierende Kommunikation mit Übertragung der Spurparameter a, b und c zur Verfügung gestellt werden.