Kommunikation zwischen PC und dSpace-Karte via RS232
Das SDE-Praktikum beinhaltet die Übertragung von Daten über eine RS232 Schnittstelle. Die Vorarbeit zu diesem Thema wurde von Daniel Klein und Steffen Sander in den vorherigen Semestern durchgeführt. Im Sommersemester 2014 wurde das Thema von Manuel Groß und Michael Deitel bearbeitet.
Einleitung
RS232 ist ein Standard für serielle Schnittstellen. Zur Kommunikation zwischen Rechnern und Peripherie kann man mit ihrer Hilfe leicht eine Verbindung aufbauen. Zwar sind dSpace-Karte und PC bereits über einen PCI-Bus miteinander verbunden, jedoch dient dieser als Programmierschnittstelle. Zur Datenübertragung zwischen den beiden werden zwei Softwarekomponenten benötigt, die PC-Seite soll die von den Sensoren und der Kamera berechneten Umgebungsdaten bündeln und als Nachricht an das auf der dSpace-Karte laufende Simulinkmodell schicken. Diese entschlüsselt die Nachricht und verwendet sie weiter.
Anforderungen aus dem Lastenheft
Folgende Anforderungen wurden für das Sommersemester 2014 im Lastenheft festgelegt:
Projektplan
Dies ist der Projektplan für das Sommersemester 2014:
PC
Die auf dem PC verwendete Kommunikationsschnittstelle ist in C++ implementiert, dies erleichtert die spätere Integrierung in die Datenverarbeitung (LIDAR/Kamera), da diese ebenfalls in C++ verfasst ist. Grundlage für die Kommunikation ist eine Bibliothek von Teunis van Beelen [1], diese beinhaltet viele Funktionen vom Aufbau einer Verbindung bis zum senden von Daten, sowohl für Windows- als auch für Linuxsysteme. Die wichtigen Funktionen sind OpenComport
und SendBuf
.
- OpenComport(int comport_number, int baudrate)
- Mithilfe dieses Befehls wird eine Kommunikation aufgebaut über die Daten übermittelt werden können. Eine Liste der verfügbaren Comports ist am Ende dieses Abschnitts zu finden, standardgemäß wird die Verbindung mit dem Comport 1 initialisiert. Neben der Angabe eines Comports erfordert die Initialisierung eine Baudrate, diese legt die Übertragungsgeschwindigkeit während einer Übermittlung fest. Eine Liste der möglichen Baudraten ist neben der, der möglichen Comports zu sehen. Für den Fall, dass eine Verbindung mit den gegebenen Variablen nicht hergestellt werden kann liefert der Befehl eine 1 als Wert zurück.
Eine Änderung des Comports oder der Baudrate wird auf PC-Seite in der Headerdatei "all_needed.h" durchgeführt. Auf der dSpace-Seite wird
- SendBuf(int comport_number, unsigned char *buf, int size)
- Dieser Befehl sendet eine zuvor definierte Anzahl an Bytes über den gegebenen Port. Die Bytes werden in ihrem Buffer Byte für Byte abgearbeitet, solange der Sendeprozess andauert wird die Verbindung geblockt. Nach Beendigung der Übertragung wird die Anzahl der Bytes bestätigt indem sie von der Funktion als Antwort zurückgegeben wird, tritt ein Fehler auf wird eine -1 übergeben.
Um Daten zu einer Nachricht zusammenzufassen, müssen sie in einem Buffer gespeichert werden und um diesen nach dem Empfangen entschlüsseln zu können wird dieser wie im Schnittstellendokument beschrieben aufgebaut. Da das Versenden der Nachrichten leicht in anderen Funktionen zu implementieren sein soll, werden alle Daten im Funktionskopf übergeben. Neben dem senden von Umgebungsdaten verfügt die Funktion über eine Dummynachricht. Im Dummybetrieb werden automatisch Daten generiert mit denen der Buffer gefüllt wird, sodass man Ein- und Ausgabe der Kommunikation im Blackbox-Verfahren kontrolliert werden können.
void send(bool dummy = 0,
float in_a = 0,
float in_b = 0,
float in_c = 0,
float in_stopplinie_entfernung = 0,
float in_x[5] = 0,
float in_y[5] = 0,
float in_breite[5] = 0,
float in_tiefe[5] = 0,
float in_objektausrichtung[5] = 0,
float in_geschwindigkeit[5] = 0,
unsigned char in_spurzuordnung = 0,
unsigned char in_stopplinie_erkannt = 0,
unsigned char in_anzahl_objekte = 0,
unsigned char in_objektnummer[5] = 0,
unsigned char in_plausibel[5] = 0)
Durch die Initialisierung mit 0 im Aufruf werden die Daten die nicht im Aufruf übergeben werden mit Null beschrieben, so ist es nicht nötig, die Werte welche im Dummymodus nicht benötigt werden, mit überflüssigen Informationen zu füllen. Eine Dummy lässt sich so mit dem Aufruf void send(1)
verwirklichen.
Im normalen Betrieb müssen sämtliche Werte in den Aufruf eingefügt werden, andernfalls kann es passieren, dass Daten an der falschen Stelle im Buffer übermittelt werden und falsch interpretiert werden oder andere Werte mit 0 übergeben werden.
Um den Buffer zu füllen gibt es von Asaad Mohammed Al-Suleihi die Funktion datatype_to_array
, diese kopiert eine gewisse Menge an Bytes in ein angegebenes Array. Der Buffer benötigt eine Gesamtgröße von 149 Bytes um alle relevanten Daten in dem gewünschten Dateiformat zu übermitteln. Ist der Buffer voll wird er verschickt.
dSpace-Karte
Die dSpace-Karte dient als zweite Hälfte der Kommunikation. Sie empfängt die Nachrichten und verarbeitet sie weiter. Die dafür nötige Software befindet sich in der Bibliothek bib_SerCom und ist im Onlinemodell des Fahrzeugs.
Um eine fehlerfreie Übertragung zu gewährleisten wird vor der Übertragung ein Handshake durchgeführt. Sobald die dSPACE–Karte alles initialisiert hat und bereit für die Kommunikation ist, signalisiert sie diesen Zustand durch das Versenden eines definierten Zeichens (DS_START_BYTE 'Y'), wird dieses vom PC empfangen antwortet er mit einem entsprechenden Zeichen (PC_START_BYTE 'R'). Ist die Antwort nicht korrekt wird der Vorgang wiederholt, nach einem erfolgreichem Handshake wird das Acknowledgementbyte (DS_ACK 'A') gesendet. Gefolgt davon werden die Sensordaten übermittelt.
Die ankommenden Daten werden in einem FIFO-Speicher hinterlegt, dadurch sind bei der Weiterverarbeitung alle Bytes in derselben Reihenfolge in der sie losgeschickt wurden. Der Empfangsblock findet sich in der RTI-Library. Man kann einstellen wie groß der Speicher für empfangene Daten sein soll, bevor sie weitergegeben werden. Der Buffer wird in eine S-Function übergeben. Hier werden mithilfe des von Herrn Al-Suleihi array_to_datatype
-Befehls je eine bestimmte Anzahl an Bytes aus dem Buffer einer beliebigen Variable zugeordnet. Diese werden aus dem Block in das Modell übergeben und dort zur Berechnung von Lenkwinkel und Geschwindigkeit genutzt.
Projektprotokoll
KW18:
- Analysieren des bisherigen Kommunikationskonzept - Handshake vom PC zur dSpace-Karte aufgebaut mit Hilfe von Matlab und Hterm
KW19:
- ControlDesk-Layout zeigt Verlauf der empfangenen und gesendeten Signale - ControlDesk-Layout zeigt auch erfolgreichen Handshake an - Pc-Console gibt in Textform die empfangenen Daten aus - Testsignale werden von C zu Matlab und zurück über RS232 versendet
KW20:
- VisualC-Code ausführlicher kommentiert - Korrekte Übertragung von Dateiformaten: bit, uint8 und float32 realisiert(fehlerhaft)
KW21:
- Ausführliche Kommentierung von Stateflow-Modellen in Matlab - Übertragung von Dateiformaten: bit, uint8 und float32 (Bugfix) - Werte können jetzt über ControlDesk manuell verschickt werden - Rücksprache mit den anderen Teams gehalten zur Kamerapolynomübertragung
KW23:
- weitere Kommentare zum Code hinzugefügt - Mit Team OSE die Einbindung des RS232-C-Codes in dessen Main besprochen und eingebunden
KW24:
- Warten auf endgültige Test auf dem Auto, da dieses in der Werkstatt ist
KW25:
- Fertigstellung Dokumentation
Verbesserungsvorschläge zum Artikel von Herrn Sander
--Ulrich Schneider (Diskussion) 13:37, 4. Feb. 2014 (CET)
- Autor fehlt
- Inhalt ist äußerst übersichtlich