Version vom 7. Januar 2023, 16:08 Uhr

Betreuer: Marc Ebmeyer
Autor: Tim Schonlau, Changlai Bao(WiSe 22/23)

Einleitung

Dieser Artikel wurde im Wintersemester 2022/23 komplett überarbeitet. Über eine genauere Beschreibung der Kommunikation hinaus wurde eine ausführliche Erklärung der Implementierung ergänzt und neu formuliert (für weitere Informationen siehe Versionshistorie).
Mitwirkende der vergangenen Semester: Sven Posner, Jonas Hokamp, Isaac Mpidi Bita, Thomas Miska, Alexander Schirrmeister, Hendrik Steffen, Lukas Honerlage, Tim Schonlau, Changlai Bao

Aufgabenstellung und Ziele

Das Modul Kommunikation realisiert den Datenaustausch der einzelnen Module des Carolo Cup Fahrzeugs (CCF). Das Ziel ist es, mithilfe von C++ Code (Visual Studio 2019) die Variablen aus der Objekt- und Spurerkennung (z.B. Spurpolynom $Y(X)=aX^2+bX+c$ ) von PC zur x86 PCI-Erweiterungskarte zu übertragen, die sich auf dem CCF befinden.
Das wird realisiert indem eine serielle RS-232 Schnittstelle zum Microcontroller, in diesem Fall der Entwicklerkarte DS1104 von dSPCACE, implementiert wird.
Die weitere Verarbeitung der Daten findet in den anderen Modulen statt, die in Simulink (2019b) implementiert und auf der dSPACE-Karte ausgeführt werden. Die Spurparameter werden z.B. in BSF - Bahn- und Spurführung verarbeitet, um den Lenkwinkel aus der aktuellen Position und dem Spurpolynom zu regeln.

Konzept

Die OSE Softwareumgebung beinhaltet die Bild- und Objekterkennung mit Laserscanner die Lidar-Verarbeitung, sowie die Implementierung der RS232 Kommunikation.
Die Kamera ist mit Ethernet an die x86-CPU verbunden, diese wiederum ist über einen COM Port über das RS-232 Protokoll mit dem dSPACE CP1104 Connector Panel verbunden. Die x86-CPU führt die "OSE_Draufsicht_Spurpolynom_RS232.exe" (C/C++ Code) aus, die einen Bildverarbeitungsalgorithmus auf das Kamerabild anwendet, um die a-, b-, c-Parameter der Fahrspur zu ermitteln. Die dSPACE Karte wird über MATLAB/Simulink programmiert und empfängt das RS-232 Protokoll über ein D-Sub Kabel.

Die OSE Softwareumgebung erkennt aus den Lidar-Daten Objekte, die in Modulen AEP - Autonomes Einparken, BSF - Bahn- und Spurführung und AuF - Antrieb und Fernbedienung benötigt werden. Mit diesen Daten kann das CCF Hindernissen auf der Teststrecke reagieren und ausweichen.

Serielle Schnittstelle: RS-232

Einen guten ersten Überblick des Recommended Standart 232 vermittelt die Definition im Wikipedia Artikel von RS-232.
Die Übertragung wird mit 8bit, also einem Byte langen Wörtern realisiert. Das heißt, dass der COM Port der x86-CPU 8 Bits in den Puffer der dSPACE Karte schreibt. Diese liest pro Zyklusschritt 8bit aus dem Puffer. Um auf diese Weise alle Bytes zu übertragen, müssen die Daten in der gleichen Reihenfolge ausgegeben und wieder eingelesen werden.
Ein Acknowledgement (ACK), Handshake, Stoppbyte und ein Parity-Byte würden die Kommunikation noch zuverlässiger machen, sind Stand Sprint2 im WiSe22/23 nicht implementiert.

Überblick Variablen

Das gesamte Datenpaket besteht aus mehreren Variablen, die der SVN: Schnittstellendokumentation zu entnehmen sind.

Ausklappbare Tabelle mit allen zu übertragenen Parametern →

Signal	Variablenname	Sender	Empfänger	Datentyp	KOS	Bedeutung
Vx,ego	V_x_ego	DS1104	PC	f32 (4 Byte)	K	Ego-Längsgeschwindigkeit des Fahrzeugs
Lenkwinkel	alpha	DS1104	PC	f32 (4 Byte)	K	Lenkwinkel, a > 0 Lenkausschlag links, a < 0 Lenkausschlag rechts
				8 Byte		Gesamtgröße des Datenpakets von dSPACE Karte zum PC
a, b, c	a, b, c	PC	DS1104	f32 (4 Byte)	K	Parameter der Fahrspur
Spurzuordnung	lane_assign	PC	DS1104	bool (1 Byte)	K	1: rechte Fahrspur / 0: linke Fahrspur
Stopplinie erkannt	stop_insight	PC	DS1104	bool (1 Byte)	K	1: Stopplinie erkannt / 0: Stopplinie nicht erkannt
Abstand Stopplinie	stop_distance	PC	DS1104	f32 (4 Byte)	K	Entfernung zur Stopplinie
nObjekte	n_objekte	PC	DS1104	uint8 (1 Byte)	-	Gesamtanzahl der relevanten Objekte (max. 5)
Objekt[n].Nummer	number[n_objekte]	PC	DS1104	uint8 (1 Byte)	-	Objektzähler
Objekt[n].x0	x_0[n_objekte]	PC	DS1104	f32 (4 Byte)	K	x-Koordinate des Objektmittelpunktes (mitte, vorn)
Objekt[n].y0	y_0[n_objekte]	PC	DS1104	f32 (4 Byte)	K	y-Koordinate des Objektmittelpunktes (mitte, vorn)
Objekt[n].b	b[n_objekte]	PC	DS1104	f32 (4 Byte)	K	Objektbreite
Objekt[n].t	t[n_objekte]	PC	DS1104	f32 (4 Byte)	K	Objekttiefe
Objekt[n].a	alpha[n_objekte]	PC	DS1104	f32 (4 Byte)	K	Objektausrichtung
Objekt[n].v	v[n_objekte]	PC	DS1104	f32 (4 Byte)	K	Betrag des Geschwindigkeitsvektors
Objekt[n].Plausibel	plausible[n_objekte]	PC	DS1104	uint8 (1 Byte)	K	Vertrauenswert für das Objekt (100: 100% vertrauenswürdig)
				149 Byte		Gesamtgröße des Datenpakets von PC zur dSPACE Karte

Dieses Diagramm veranschaulicht die zu sendenden Daten:

Am Anfang wird das Startbyte mit 10101010(BIN) = 170(DEC) gewählt. Darauf folgt das Spurpolynom mit den drei Polynomkoeffizienten. Da jeder Koeffizient mit einer Genauigkeit eines floats, also 32bit = 8byte berechnet wird, sind es ingesamt 12Byte für das Fahrspurpolynom. Die Spurerkennung setzt sich zwei binären Werten, die dennoch mit je einem byte übertragen werden zusammen, um die Fahrspur oder :Stopplinie zu erfassen. Darauf folgt wieder ein 4Byte langer Parameter mit der Distanz zur Stopplinie.
Die Anzahl der Lidar-Objekte wird mit einem Byte übertragen, die Eigenschaftsparameter wie Größe, Position, Geschwindigkeit werden ebenfalls jeweils mit 8Byte übertragen, die Objektnummer und der Vertrauenswert wird mit einem Byte gesendet. So ergibt sich eine gesamte Paketlänge von 150 Byte, die beispielhaft mit 19200 baud (byte pro Sekunde) in einer Sekunde 128 mal übertragen wird.

Softwarearchitektur für die Kommunikation

Die für die OSE Softwareumgebung relevanten Dateien werden im folgendem Diagramm abgebildet.

Beschreibung der Implementierung

Die OSE Softwareumgebung umfasst drei Themenbereiche:

Die Linienerkennung, mit der die Fahrspur berechnet oder die Stopplinie identifiziert wird.
Zweitens die Objekterkennung die aus LIDAR Daten berechnet werden (Noch nicht vollständig im Diagramm! | Stand Sprint1 WS22/23).
Die Implementierung einer RS-232 Kommunikation mit der rs-232.c-Bibliothek von Teunis van Beelen.

Zu Beginn werden in der Hauptklasse der OSE Softwareumgebung "main.h" die Objekt- und Spurerkennung durchgeführt. So werden alle für das Fahrzeug relevanten Informationen generiert Die gesammelten Daten (Spurparameter, Stopplinie, LiDAR-Objekte, etc.) werden im Anschluss in einem Struct zusammengeführt. Mit diesem Struct wird die Funktion RS232_SendDataBigEndianFirst aufgerufen, die mit der Funktion RS232_SendByte() aus "RS232Comm.h" das Datenpaket an die dSPACE-Karte schickt.
Vom PC wird jeder Parameter in 4 Byte aufgesplittet. Es werden, inklusive 5 LiDAR Objekte, insgesamt 47 Parameter nacheinander versendet. Als erstes werden die 4 Byte des a-Parameters empfangen, dann wird der b-Parameter, anschließend der c-Parameter und so weiter. Die Daten werden in der gleichen Reihenfolge empfangen, wie sie auch versendet wurden. Um sicher zu stellen, dass der a-Parameter immer als erstes bearbeitet wird, wird einen START_BYTE von PC zu der dSPACE-Karte gesendet. Dieser wird bewusst als 10101010(BIN) = 170(DEC) gewählt. Wichtig zu beachten ist, dass die Daten im PC als Little-Endian und auf der dSPACE-Karte als Big-Endian gespeichert sind.

Konfiguration der dSPACE-Karte

RTI Block im Simulink online Modell (CCF_online → SEN - Sensoren - online → SenKam - Kamera)

Mit der RTI Toolbox von dSPACE wird eine Simulink-Bibliothek für die serielle Schnittstelle bereitgestellt. Hierfür sollte das MATLAB®/Simulink online Modell des CCF gestartet werden. Nachdem die CCF_online.slx in Simulink geöffnet wurde, kann mit Strg + L die verlinkte Bibliothek CCF_online → SEN - Sensoren - online → SenKam - Kamera geöffnet werden. Empfehlenswert ist ein Blick in die Dokumentation/Hilfe von dSPACE, die über das Kontextmenü geöffnet werden kann. Die serielle Kommunikation wird mittels des sogenannten DS1104SER_SETUP -Blocks in Simulink initialisiert, mit einem Doppelklick auf den Block können die Einstellungen des Busses konfiguriert werden: Für die Fahrzeugskommunikation muss auf beiden Seiten eine gleiche Baudrate bestimmt werden.

Im Simulink online Modell werden die gesendeten Bytes mithilfe einer S-Function aufgeschlüsselt. Diese können in dSPACE Control Desk visualisiert und getestet werden.
Hier ist eine ausführlichere Beschreibung der S-Function im 'online Modell' zu finden:

Dekodierung RS-232 in Simulink

Alte Wiki-Artikel zur Kommunikationsimplementierung:
Übertragen des Spurpolynoms Kommunikation zwischen PC und dSpace-Karte (vorheriger Ansatz)

Kommunikation und Diagnoseschnittstelle (aktueller Ansatz)

Implementierung in Visual Studio

Die Umsetzung in Visual Studio orientiert sich am oben beschrieben Ablauf.
Für die konkrete Implementierung der Datenübertragung wurden die folgenden beiden ausführlichen Artikel verfasst:

(Diese beiden Artikel müssen noch zu einem zusammengefasst werden)

Anleitung für das ONLINE-Modell

Nutzen sie bitte MATLAB 2019b
Achten Sie bitte auf der Solver des Blocks --> Fixed Step nicht auf auto
Lesen Sie die Wiki-Artikeln durch
Notieren Sie Fehlermeldungen und Warnings
Warnings sind sofort zu beseitigen beim Erstellen einer neuen Bibliothek!

Tests der Kommunikation

Anforderungen

Über die RS-232-Schnittstelle müssen die Parameter des zu steuernden Fahrzeugs getestet werden. Das DS1104 gibt die Fahrzeuggeschwindigkeit (Vx,Ego) und den Lenkwinkel α an den PC weiter. Im Gegenzug liefert der PC dem DS1104 die Spurparameter a, b und c sowie die Parameter der Hindernisse. In den Tabellen 1 und 2 sind alle Parameter aufgeführt, die geprüft werden müssen.

Tabelle 1: Übertragene Daten DS1104 zu PC
Signalname	Datentyp	Beschreibung
V_x_ego	float32 (4 Byte)	Ego-Längsgeschwindigkeit des Fahrzeugs
alpha	float32 (4 Byte)	Lenkwinkel: α > 0 Lenkausschlag links, α < 0 Lenkausschlag rechts
Gesamtgröße des Datenpakets		8 Byte

Da momentan für den Handshake 16 Byte große Pakete übertragen werden sind auch die Datenpakete von dSpace zu PC 16 Byte groß(zwei float64 Werte statt float32). Dies sollte in Zukunft geändert werden.

Tabelle 2: Übertragene Daten PC zu DS1104
Signalname	Datentyp	Beschreibung
a	float32 (4 Byte)	Fahrspurparameter
b	float32 (4 Byte)	Fahrspurparameter
c	float32 (4 Byte)	Fahrspurparameter
lane_asign	bool (1 Byte)	Spurzuordnung: 1 = rechte Fahrspur, 0 = linke Fahrspur
stop_insight	bool (1 Byte)	1 = Stopplinie erkannt, 0 = keine Stopplinie erkannt
stop_distance	float32 (4 Byte)	Entfernung zur Stopplinie
n_objekte	uint8 (1 Byte)	Anzahl relevanter Objekte (maximal 5)
number[n_objekte]	uint8 (1 Byte)	Objektzähler
x_0[n_objekte]	float32 (4 Byte)	x-Koordinate des Objektmittelpunktes (mitte, vorn)
y_0[n_objekte]	float32 (4 Byte)	y-Koordinate des Objektmittelpunktes (mitte, vorn)
b[n_objekte]	float32 (4 Byte)	Objektbreite
t[n_objekte]	float32 (4 Byte)	Objekttiefe
alpha[n_objekte]	float32 (4 Byte)	Objektausrichtung
v[n_objekte]	float32 (4 Byte)	Betrag des Geschwindigkeitsvektors
plausible[n_objekte]	uint8 (1 Byte)	Vertrauenswert für das Objekt in Prozent ( 0 = minimale Vertrauen, 100 = maximale Vertrauen)
Gesamtgröße des Datenpakets		149 Byte

Testdokumentation

Tabelle 3: Links zur Testdokumentation
Datum	Link
Februar 2019	Kommunikation zwischen PC und dSpace-Karte via RS232
Januar 2020	Übertragen des Spurpolynoms
Januar 2022	Kommunikation RS232 zwischen PC und DS1104
Juli 2022	Kom - Kommunikation: Test der Kommunikation zw. PC und DS1104
Dezember 2022	Test der RS232-Kommunikation (Abschlusstest WiSe 22/23)

Programmierrichtlinien

Schnittstellendokumentation

→ Schnittstellendokumentation

Namenskonvetion

→ Namenskonvention

Alte Wiki Artikel

Tutorial - Bussysteme in Matlab Autor: John Kneib
Verbindung zum Fahrzeug
- VNC-Verbindung
- Von Simulink zu ControlDesk
Aufbau einer virtuellen Kommunikationsumgebung
- Erstellung eines virtuelle Port
- Serielle Visualisierung mit HTerm
LiDAR
- Objekterkennung mit LiDAR Hokuyo URG-04LX Autor: Michael Deitel Manuel Groß Bearbeitet von: Benedikt Wulowitsch, John Kneib
- Inbetriebnahme und Objekterkennung des LiDAR Hokuyo URG-04LX in MATLAB Autor: Yu Peng
- Inbetriebnahme und Objekterkennung des RP Lidar A1M8 in MATLAB Autor:Thomas Miska
- Kommunikation Hokuyo LiDAR via USB Autor:Isaac Mpidi Bita
Kamera
- Umrechnung von Bildkoordinaten ins Weltkoordinatensystem
- Spurerkennung (Vorheriger Ansatz) Autor: Konstantin Wotschel
- Objekterkennung mit Kamera VR-Magic Autor: Christian Hauke 7. Feb. 2014 (CET)
- Bildentzerrung und KOS-Transformation mit OpenCV (aktueller Ansatz) Autor: Luca Di Lillo, Tim Bexten in SS2019

→ zurück zum Hauptartikel: Praktikum SDE

@@ Zeile 240: / Zeile 240: @@
 = Tests der Kommunikation =
+==Anforderungen==
+Über die RS-232-Schnittstelle müssen die Parameter des zu steuernden Fahrzeugs getestet werden. Das DS1104 gibt die Fahrzeuggeschwindigkeit (Vx,Ego) und den Lenkwinkel α an den PC weiter. Im Gegenzug liefert der PC dem DS1104 die Spurparameter a, b und c sowie die Parameter der Hindernisse. In den Tabellen 1 und 2 sind alle Parameter aufgeführt, die geprüft werden müssen.
 {| class="wikitable"
+|+ style = "text-align: left"|Tabelle 1: Übertragene Daten DS1104 zu PC
+! scope="col"| Signalname
+! scope="col"| Datentyp
+! scope="col"| Beschreibung
+|-
+! scope="row"| V_x_ego
+| float32 (4 Byte)
+| Ego-Längsgeschwindigkeit des Fahrzeugs
+|-
+! scope="row"| alpha
+| float32 (4 Byte)
+| Lenkwinkel: α > 0 Lenkausschlag links, α < 0 Lenkausschlag rechts
+|-
+! scope="row" colspan="2"| Gesamtgröße des Datenpakets
+| 8 Byte
+|}
+Da momentan für den Handshake 16 Byte große Pakete übertragen werden sind auch die Datenpakete von dSpace zu PC 16 Byte groß(zwei float64 Werte statt float32). Dies sollte in Zukunft geändert werden.
+{| class="wikitable"
+|+ style = "text-align: left"|Tabelle 2: Übertragene Daten PC zu DS1104
+! scope="col"| Signalname
+! scope="col"| Datentyp
+! scope="col"| Beschreibung
+|-
+! scope="row"| a
+| float32 (4 Byte)
+| Fahrspurparameter
+|-
+! scope="row"| b
+| float32 (4 Byte)
+| Fahrspurparameter
+|-
+! scope="row"| c
+| float32 (4 Byte)
+| Fahrspurparameter
+|-
+! scope="row"| lane_asign
+| bool (1 Byte)
+| Spurzuordnung: 1 = rechte Fahrspur, 0 = linke Fahrspur
+|-
+! scope="row"| stop_insight
+| bool (1 Byte)
+| 1 = Stopplinie erkannt, 0 = keine Stopplinie erkannt
+|-
+! scope="row"| stop_distance
+| float32 (4 Byte)
+| Entfernung zur Stopplinie
+|-
+! scope="row"| n_objekte
+| uint8 (1 Byte)
+| Anzahl relevanter Objekte (maximal 5)
+|-
+! scope="row"| number[n_objekte]
+| uint8 (1 Byte)
+| Objektzähler
+|-
+! scope="row"| x_0[n_objekte]
+| float32 (4 Byte)
+| x-Koordinate des Objektmittelpunktes (mitte, vorn)
+|-
+! scope="row"| y_0[n_objekte]
+| float32 (4 Byte)
+| y-Koordinate des Objektmittelpunktes (mitte, vorn)
+|-
+! scope="row"| b[n_objekte]
+| float32 (4 Byte)
+| Objektbreite
+|-
+! scope="row"| t[n_objekte]
+| float32 (4 Byte)
+| Objekttiefe
+|-
+! scope="row"| alpha[n_objekte]
+| float32 (4 Byte)
+| Objektausrichtung
+|-
+! scope="row"| v[n_objekte]
+| float32 (4 Byte)
+| Betrag des Geschwindigkeitsvektors
+|-
+! scope="row"| plausible[n_objekte]
+| uint8 (1 Byte)
+| Vertrauenswert für das Objekt in Prozent ( 0 = minimale Vertrauen, 100 = maximale Vertrauen)
+|-
+! scope="row" colspan="2"| Gesamtgröße des Datenpakets
+| 149 Byte
+|}
+==Testdokumentation==
+{| class="wikitable"
+|+ style = "text-align: left"|Tabelle 3: Links zur Testdokumentation
 ! style="font-weight: bold;" | Datum
 ! style="font-weight: bold;width: 600px;" | Link

Kom - Kommunikation: Unterschied zwischen den Versionen