Kom - Kommunikation: Unterschied zwischen den Versionen
K (→Aufgabenstellung und Ziele: Formel mit math Erweiterung dargestellt) |
K (Größe Bilder auf 16:9 angepasst) |
||
Zeile 9: | Zeile 9: | ||
Die Kamera ist mit Ethernet an die x86-CPU verbunden, diese wiederum ist über einen [https://learn.microsoft.com/en-us/windows-hardware/drivers/serports/configuration-of-com-ports COM Port] über das RS-232 Protokoll mit der dSPACE Karte 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. </br> | Die Kamera ist mit Ethernet an die x86-CPU verbunden, diese wiederum ist über einen [https://learn.microsoft.com/en-us/windows-hardware/drivers/serports/configuration-of-com-ports COM Port] über das RS-232 Protokoll mit der dSPACE Karte 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. </br> | ||
[[Datei:Schema_Konzept_SDE_CCF_Kommunikation.PNG| | [[Datei:Schema_Konzept_SDE_CCF_Kommunikation.PNG|thumb|center|700px|Schema des Kommunikations-Konzepts nach Schnittstellen Dokumentation (Regelkreis mit dSPACE-Karte stark vereinfacht) ]] | ||
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. | 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. | ||
Zeile 110: | Zeile 110: | ||
Die für die [[OSE Softwareumgebung]] relevanten Dateien werden im folgendem Diagramm abgebildet. | Die für die [[OSE Softwareumgebung]] relevanten Dateien werden im folgendem Diagramm abgebildet. | ||
[[Datei:Allgemeine_SH_Kommunikation.png|center]] | [[Datei:Allgemeine_SH_Kommunikation.png|thumb|700px|center]] | ||
===Beschreibung der Implementierung=== | ===Beschreibung der Implementierung=== | ||
Zeile 116: | Zeile 116: | ||
Die Hauptklasse der [[OSE Softwareumgebung]] "main.h" ruft die Funktion '''RS232_SendDataBigEndianFirst()''' auf, 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. Da 3 Parameter versendet werden, werden pro Übertragung 12 Byte benötigt, um die a-,b- und c-Parameter an der dSPACE-Karte zu bilden. Als erstes werden die 4 Byte des a-Parameters empfangen, dann wird des b-Parameter, anschließend der c-Parameter. 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 [https://de.wikipedia.org/wiki/Byte-Reihenfolge#Little-Endian-Format Little-Endian] und auf der dSPACE-Karte als [https://de.wikipedia.org/wiki/Byte-Reihenfolge#Big-Endian-Format Big-Endian] gespeichert sind. | Die Hauptklasse der [[OSE Softwareumgebung]] "main.h" ruft die Funktion '''RS232_SendDataBigEndianFirst()''' auf, 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. Da 3 Parameter versendet werden, werden pro Übertragung 12 Byte benötigt, um die a-,b- und c-Parameter an der dSPACE-Karte zu bilden. Als erstes werden die 4 Byte des a-Parameters empfangen, dann wird des b-Parameter, anschließend der c-Parameter. 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 [https://de.wikipedia.org/wiki/Byte-Reihenfolge#Little-Endian-Format Little-Endian] und auf der dSPACE-Karte als [https://de.wikipedia.org/wiki/Byte-Reihenfolge#Big-Endian-Format Big-Endian] gespeichert sind. | ||
[[Datei:BitReihenfolge.png| | [[Datei:BitReihenfolge.png|700px|center]] | ||
= RS232-Bus Initialisierung = | = RS232-Bus Initialisierung = |
Version vom 23. November 2022, 16:06 Uhr
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 ) 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 der dSPACE Karte 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 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.
Überblick Variablen
- PC zu dSpace
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 Objekt (0=min,255=max) |
149 Byte | Gesamtgröße des Datenpakets |
- dSpace 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 |
8 Byte | Gesamtgröße des Datenpakets |
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. Erstens 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). Drittens die Implementierung einer RS-232 Kommunikation mit der rs-232.c-Bibliothek von Teunis van Beelen.
Die Hauptklasse der OSE Softwareumgebung "main.h" ruft die Funktion RS232_SendDataBigEndianFirst() auf, 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. Da 3 Parameter versendet werden, werden pro Übertragung 12 Byte benötigt, um die a-,b- und c-Parameter an der dSPACE-Karte zu bilden. Als erstes werden die 4 Byte des a-Parameters empfangen, dann wird des b-Parameter, anschließend der c-Parameter. 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.
RS232-Bus Initialisierung
Initialisierung auf der dSPACE-Karte
dSPACE GmbH stellt eine Simulink-Bibliothek für die serielle Schnittstelle zur Verfügung. Beispiele zur Anwendung von dieser sind in der Kommunikationsordner in ..\Teams\Kom\Demos\DEMO dSPACE Kommunikation vorhanden. Die serielle Kommunikation wird mittels des sogenannten DS1104SER_SETUP initialisiert werden. Dieser muss auch auf der Simulink-Modell enthalten sein. Beim Doppelklick auf dem Block kommt die relevanten Einstellungen des Busses und können dementsprechend eingestellt werden. Für die Fahrzeugskommunikation wird 115200 als Baudrate genommen werden. Die Kommunikation erfolgt erstmal ohne Handshake.
Alte Wiki-Artikel zur Kommunikationsimplementierung:
Übertragen des Spurpolynoms
Kommunikation zwischen PC und dSpace-Karte (vorheriger Ansatz)
Kommunikation und Diagnoseschnittstelle (aktueller Ansatz)
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!
Tutorial - Bussysteme in Matlab
Autor: John Kneib
Verbindung zum Fahrzeug
VNC-Verbindung
Von Simulink zu ControlDesk
Aufbau einer virtuellen Kommunikationsumgebung
Fehlermeldung MSVCP140D bei ComTest.exe
Autor: Tim Schonlau, Changlai Bao in WS2022/23
Beim ersten Start fehlen bestimmte Windows Bibliotheken. Das Kompilieren der Datei "ComTest.vcxproj" mit Visual Studio (2019) löst das Problem.
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
Tests der Kommunikation
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 |
Wichtige Dokumenten in SVN
- Schnittstellendokumentation
Im SVN ist der aktuelle Stand der Schnittstelle zwischen dSPACE-1104-Karte und PC dokumentiert.
→ SVN: Schnittstellendokumentation
- Namenskonvetion
Im SVN sind Programmierrichtlinien bezüglich Namenskonvention unter: Programmierrichtlinien: Namenskonvention gespeichert.
→ zurück zum Hauptartikel: Praktikum SDE