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

Aus HSHL Mechatronik
Zur Navigation springen Zur Suche springen
(Lesbarkeit PAP verbessert)
 
(9 dazwischenliegende Versionen von einem anderen Benutzer werden nicht angezeigt)
Zeile 76: Zeile 76:
|}
|}


Da die Einbindung des Lidars und der Kamera auf neuem Wege 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 Übertragung weiterer 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.
====PC zu dSPACE====
{| class="wikitable"
|-
! 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"| 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
| 149 Byte
|}
Es wird zudem der Lenkwinkel und die Geschwindigkeit des Fahrzeugs von der dSPACE-Karte an den PC verschickt. Dies muss ebenfalls umgesetzt werden. Eine Auflistung der Daten ist in der nachfolgenden Tabelle zu sehen. Zudem soll eine vollständige Dokumentation der Ergebnisse erfolgen.
====dSPACe zu PC====
{| class="wikitable"
|-
! scope="col"| Signalname
! scope="col"| Datentyp
! scope="col"| Beschreibung
|-
! scope="row"| alpha
| float32 (4 Byte)
| Lenkwinkel des Fahrzeigs
|-
! scope="row"| b
| float32 (4 Byte)
| Fahrspurparameter
|-
! scope="row" colspan="2"| Gesamtgröße des Datenpakets
| 8 Byte
|}




Zeile 177: Zeile 84:
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. Zudem muss die Byte-Ordnung der Variablen im Speicher getauscht werden. Der PC auf dem das C-Programm arbeitet mit little-endian, wohingegen die dSPACE-Karte big-endian verwendend. Die Rotation erfolgt letztlich durch einen Zugriff auf die Speicherzelle mittels Zeiger und einem Versand in umgedrehter Reigenfolge. Hierdurch wird zu nächst das letzte Element der Variable versandt.
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. Zudem muss die Byte-Ordnung der Variablen im Speicher getauscht werden. Der PC auf dem das C-Programm arbeitet mit little-endian, wohingegen die dSPACE-Karte big-endian verwendend. Die Rotation erfolgt letztlich durch einen Zugriff auf die Speicherzelle mittels Zeiger und einem Versand in umgedrehter Reigenfolge. Hierdurch wird zu nächst das letzte Element der Variable versandt.


<gallery mode = "traditional" widths=400px heights=1000px>
 
File:Send_Data_Big_Endian_First.png|Abb. 2: Statische Übertragung
[[File:Send_Data_Big_Endian_First.png|Abb. 6: Statische Übertragung|none|1200px]]
</gallery>
 


Das zweite Konzept vergleicht zunächst den Wert der alten Variable mit dem Wert der neuen Variable. Wird hierbei ein Grenzwert überschritten oder kommt es zu einem Flankenwechsel, so werden die Daten übertragen. Fall nicht, wird auf die Übertragung dieser Daten verzichtet und das nächste Datenpaket überprüft. Die Daten werden hierbei in drei Gruppen/Datenpakete eingeteilt: Spurdaten, Stopplinie und Lidar-Objekte. Durch diese Methode kann letztlich die Menge der versendeten Daten stark verringert werden. Im Worst Case werden weiterhin 149 Byte versendet. Im Best Case hingegen kann auf eine Übertragung der Daten verzichtet werden.
Das zweite Konzept vergleicht zunächst den Wert der alten Variable mit dem Wert der neuen Variable. Wird hierbei ein Grenzwert überschritten oder kommt es zu einem Flankenwechsel, so werden die Daten übertragen. Fall nicht, wird auf die Übertragung dieser Daten verzichtet und das nächste Datenpaket überprüft. Die Daten werden hierbei in drei Gruppen/Datenpakete eingeteilt: Spurdaten, Stopplinie und Lidar-Objekte. Durch diese Methode kann letztlich die Menge der versendeten Daten stark verringert werden. Im Worst Case werden weiterhin 149 Byte versendet. Im Best Case hingegen kann auf eine Übertragung der Daten verzichtet werden.


<gallery mode = "traditional" widths=600px heights=510px>
 
File:Sende_Daten.png|Abb. 3: Dynamsiche Übertragung
[[File:Sende_Daten.png|Abb. 7: Dynamsiche Übertragung|1300px|none|righte]]
File:Auswahl_Daten.png|Abb. 4: Auswahl, welche Daten dynamisch übertragen werden
[[File:Auswahl_Daten.png|Abb. 8: Auswahl, welche Daten dynamisch übertragen werden|900px|right|none]]
</gallery>
 


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. Zunächst sendet die dSPACE Karte ein Startbyte an den PC. Dieser reagiert mit einem weiteren Startbyte. Empfängt die dSPACE Karte dieses Startbyte, so sendet sie ein ACK und bestätigt somit den Eingang der Daten. Durch den Empfang des ACK am PC ist der Handshake abgeschlossen.
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. Zunächst sendet die dSPACE Karte ein Startbyte an den PC. Dieser reagiert mit einem weiteren Startbyte. Empfängt die dSPACE Karte dieses Startbyte, so sendet sie ein ACK und bestätigt somit den Eingang der Daten. Durch den Empfang des ACK am PC ist der Handshake abgeschlossen.


<gallery mode = "traditional" widths=400px heights=540px>
 
File:HandshakeRS232.png|Abb. 5: Handshake
[[File:HandshakeRS232.png|Abb. 9: Handshake|900px|right]]
</gallery>
 


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 abgefangen 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.
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 abgefangen 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.
Zeile 202: Zeile 109:
Das Konzept hierfür ist der nachfolgenden Abbildung zu sehen.
Das Konzept hierfür ist der nachfolgenden Abbildung zu sehen.


<gallery mode = "traditional" widths=400px heights=600px>
 
File:Empfange_daten.png|Abb. 6: Empfangen von Daten am PC
[[File:Empfange_daten.png|Abb. 10: Empfangen von Daten am PC|800px|right]]
</gallery>
 


== Programmierung ==
== Programmierung ==
Zeile 213: Zeile 120:
== Komponententest ==
== Komponententest ==


<gallery mode = "traditional" widths=1150px heights=300px>
Abschließend wurde der nachfolgende Komponententest durchgeführt, um die Funktion des Moduls Kommunikation zu testen. Hierbei wurde insbesondere der Handshake, das Senden und Empfangen sowie die Änderung der Bytereihenfolge getestet. Wie in der nachfolgenden Abbildung zu sehen, wurden alle Testfälle erfolgreich abgeschlossen. Daher lässt sich sagen, dass das Modul Kommunikation zum derzeitigen Stand voll funktionsfähig ist.
File:Komponententest RS232Comm.png|Abb. 5: Pflichtenheft
 
<gallery mode = "traditional" widths=1150px heights=290px>
File:Komponententest RS232Comm.png|Abb. 11: Komponententest
</gallery>
</gallery>


Zeile 220: Zeile 129:


Die Kommunikation findet über RS232 statt und wird durch ein in C/C++ geschriebenes Programm auf dem PC gesteuert. Sie kann mit dem aktuellen Stand alle Daten von der Spurerkennung, der Stopplinienerkennung und dem Lidar zur dSpace-Karte übertragen. Außerdem ist können Daten von der dSpace-Karte am PC empfangen werden. Aktuell arbeitet die Kommunikation mit einer Baudrate von 19200. Das maximum der dSpace-Karte liegt eigentlich bei 115200. Diese Geschwindigkeit kann jedoch nicht erreicht werden, da bei einer höheren Baudrate als 19200 ein Taskoverrun auftritt. Die dSpace-Karte kann dann die von der Kommunikation ausgelösten Interrupts nicht schnell genug abarbeiten. Dieses Problem genauer zu untersuchen und wenn möglich zu lösen ist eine mögliche Aufgabe für ein folgendes Team.
Die Kommunikation findet über RS232 statt und wird durch ein in C/C++ geschriebenes Programm auf dem PC gesteuert. Sie kann mit dem aktuellen Stand alle Daten von der Spurerkennung, der Stopplinienerkennung und dem Lidar zur dSpace-Karte übertragen. Außerdem ist können Daten von der dSpace-Karte am PC empfangen werden. Aktuell arbeitet die Kommunikation mit einer Baudrate von 19200. Das maximum der dSpace-Karte liegt eigentlich bei 115200. Diese Geschwindigkeit kann jedoch nicht erreicht werden, da bei einer höheren Baudrate als 19200 ein Taskoverrun auftritt. Die dSpace-Karte kann dann die von der Kommunikation ausgelösten Interrupts nicht schnell genug abarbeiten. Dieses Problem genauer zu untersuchen und wenn möglich zu lösen ist eine mögliche Aufgabe für ein folgendes Team.
== Link zum Quelltext in SVN ==


----
----
→ zurück zum Hauptartikel: [[Praktikum_SDE|SDE Praktikum Autonomes Fahren]]
→ zurück zum Hauptartikel: [[Praktikum_SDE|SDE Praktikum Autonomes Fahren]]

Aktuelle Version vom 30. November 2022, 23:41 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. 1: Lastenheft REQ10.3160

  • Abb. 2: Lastenheft REQ10.3275

    Abb. 2: Lastenheft REQ10.3275

  • Abb. 3: Lastenheft REQ10.3280

    Abb. 3: Lastenheft REQ10.3280

  • Abb. 4: Lastenheft REQ10.3290

    Abb. 4: Lastenheft REQ10.3290

  • Abb. 5: Pflichtenheft

    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 bestehendes Programm auszuwählen, mit dem die Kommunikation umgesetzt werden soll. Die Unterschiede und Gemeinsamkeiten der beiden Programme sind in den nachfolgenden Tabelle aufgelistet.

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


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 funktionsfähige Kommunikation mit Übertragung der Spurparameter a, b und c zur Verfügung gestellt werden.

Konzept für die Übertragung an die dSPACE-Karte

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. Zudem muss die Byte-Ordnung der Variablen im Speicher getauscht werden. Der PC auf dem das C-Programm arbeitet mit little-endian, wohingegen die dSPACE-Karte big-endian verwendend. Die Rotation erfolgt letztlich durch einen Zugriff auf die Speicherzelle mittels Zeiger und einem Versand in umgedrehter Reigenfolge. Hierdurch wird zu nächst das letzte Element der Variable versandt.


Abb. 6: Statische Übertragung
Abb. 6: Statische Übertragung


Das zweite Konzept vergleicht zunächst den Wert der alten Variable mit dem Wert der neuen Variable. Wird hierbei ein Grenzwert überschritten oder kommt es zu einem Flankenwechsel, so werden die Daten übertragen. Fall nicht, wird auf die Übertragung dieser Daten verzichtet und das nächste Datenpaket überprüft. Die Daten werden hierbei in drei Gruppen/Datenpakete eingeteilt: Spurdaten, Stopplinie und Lidar-Objekte. Durch diese Methode kann letztlich die Menge der versendeten Daten stark verringert werden. Im Worst Case werden weiterhin 149 Byte versendet. Im Best Case hingegen kann auf eine Übertragung der Daten verzichtet werden.


righte
righte
Abb. 8: Auswahl, welche Daten dynamisch übertragen werden
Abb. 8: 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. Zunächst sendet die dSPACE Karte ein Startbyte an den PC. Dieser reagiert mit einem weiteren Startbyte. Empfängt die dSPACE Karte dieses Startbyte, so sendet sie ein ACK und bestätigt somit den Eingang der Daten. Durch den Empfang des ACK am PC ist der Handshake abgeschlossen.


Abb. 9: Handshake
Abb. 9: Handshake


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 abgefangen 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.

Konzept für die Übertragung an den PC

Für das Versenden der beiden Daten an den PC wurde ebenfalls ein Konzept erarbeitet. Um ein effizientes Programm zu ermöglichen, sollte bei Empfang von Daten im Eingangspuffer ein Interrupt oder Event ausgelöst werden. Nach einiger Recherche sind wir auf die fileapi von Microsoft gestoßen, welcher bereits beim Senden und Empfangen von Daten eingesetzt wird. Innerhalb der fileapi gibt es die Funktion WaitCommEvent, mit dessen Hilfe auf ein Event am Eingangspuffer gewartet werden kann. Jedoch ist hierbei das Problem, dass die Funktion solange wartet, bis Daten empfangen wurden. Hierdurch stoppt das gesamte Programm an dieser Stelle. Um diese Problematik zu umgehen, wird der Empfang der Daten in einem zweiten Thread umgesetzt. Hierdurch kann der Hauptthread weiterarbeiten und auf empfangene Daten im zweiten Thread reagieren.

Das Konzept hierfür ist der nachfolgenden Abbildung zu sehen.


Abb. 10: Empfangen von Daten am PC
Abb. 10: Empfangen von Daten am PC


Programmierung

Die Programmierung der Kommunikation via RS232 wurde in Visual Studio umgesetzt. Wie bereits erwähnt, wird der Empfang von Daten am PC mit Hilfe eines zweiten Thread umgesetzt. Hierdurch kann das Hauptprogramm weiter arbeiten, während auf Daten gewartet wird. Durch den zweiten Thread wird jedoch die Möglichkeit des Debuggen eingeschränkt, da zwischen zwei Threads gewechselt wird. Zudem muss die Lebenszeit des zweiten Thread durch den Hauptthread verwaltet werden. Da derzeit die empfangenen Daten noch nicht weiter verwendet werden, wird die Erstellung des zweiten Threads per define aus kommentiert. Hierdurch kann es zu keinen unerwartete Problemen bei Ausführung des Programms kommen. Das Einbinden des zweiten Thread kann in der allneeded.h eingestellt werden.

Komponententest

Abschließend wurde der nachfolgende Komponententest durchgeführt, um die Funktion des Moduls Kommunikation zu testen. Hierbei wurde insbesondere der Handshake, das Senden und Empfangen sowie die Änderung der Bytereihenfolge getestet. Wie in der nachfolgenden Abbildung zu sehen, wurden alle Testfälle erfolgreich abgeschlossen. Daher lässt sich sagen, dass das Modul Kommunikation zum derzeitigen Stand voll funktionsfähig ist.

  • Abb. 11: Komponententest

    Abb. 11: Komponententest

Zusammenfassung

Die Kommunikation findet über RS232 statt und wird durch ein in C/C++ geschriebenes Programm auf dem PC gesteuert. Sie kann mit dem aktuellen Stand alle Daten von der Spurerkennung, der Stopplinienerkennung und dem Lidar zur dSpace-Karte übertragen. Außerdem ist können Daten von der dSpace-Karte am PC empfangen werden. Aktuell arbeitet die Kommunikation mit einer Baudrate von 19200. Das maximum der dSpace-Karte liegt eigentlich bei 115200. Diese Geschwindigkeit kann jedoch nicht erreicht werden, da bei einer höheren Baudrate als 19200 ein Taskoverrun auftritt. Die dSpace-Karte kann dann die von der Kommunikation ausgelösten Interrupts nicht schnell genug abarbeiten. Dieses Problem genauer zu untersuchen und wenn möglich zu lösen ist eine mögliche Aufgabe für ein folgendes Team.

→ zurück zum Hauptartikel: SDE Praktikum Autonomes Fahren

Abgerufen von „https://wiki.hshl.de/wiki/index.php?title=Datenübertragung_zwischen_PC_und_dSPACE_Karte&oldid=97565“