Objekterkennung mit Laserscanner

→ zurück zum Hauptartikel: Praktikum SDE
→ zurück zu OSE - Objekt - und Spurerkennung

---

Autor: Michael Deitel Manuel Groß
Bearbeitet von: Patricio Emiliano Hernandez Murga und Moritz-Ben-Joe Kühnrich

Einleitung

Die Objekterkennung mit Laserscanner ist einer der Arbeitsbereiche des SDE-Praktikums. Die Tätigkeit besteht aus Auswertung der Rohdaten und umformen dieser in eine Objektliste, welche Daten zu den vom Laserscanner erfassten Objekten enthält. Im Wintersemester 2014/2015 wurde dieses Themena von Michael Deitel und Manuel Groß bearbeitet. Die Vorarbeit zu diesem Thema wurde von Jens Ruhrlaender geleistet. Das Thema wird im Wintersemester 2022/2023 von Patricio Emiliano Hernandez Murga und Moritz-Ben-Joe Kühnrich neu aufgerollt.

Inhalt

Hardware Inbetriebnahme

Zur Objekterkennung mittels LIDAR wird der Laserscanner URG-04LX der Firma Hokuyo verwendet.

Laserscanner URG-04LX (Originaldatei)

Im Praktikum stehen zwei Laserscanner zur Verfügung. Ein auf dem Fahrzeug verbauter und ein nicht verbauter zum Testen ohne das Fahrzeug für andere Teams zu blockieren. Mit beiden können die nachfolgenden Programme ausgeführt werden. Der Lidar, der auf dem Fahrzeug verbaut wurde ist mit schwarzem Klebeband oben abgeklebt (Klebestelle im Bild grüner Pfeil), da die ansonsten sichtbaren weißen Linien auf dem Lidar die Kamera irritieren. Der Lidar ist am Fahrzeug mit 2 Schrauben befestigt (siehe rote Pfeile im Bild).

Beim erstmaligen Anschluss werden die Treiber nicht automatisch installiert. Diese müssen manuell eingebunden werden. Die Treiber sind im SVN unter

Um den LiDAR dann über C/C++ zu verwenden muss die dazugehörige URG-Bibliothek eingebunden werden. Eine detaillierte Anleitung dafür befindet sich hier

LiDAR-Framework

Es wurde ein Framework erstellt, dies hält das Programm modular und es ist sehr einfach eine anderen LiDAR-Sensor einzupflegen. Das LiDAR Framework ist wie folgt aufgebaut LiDAR-Framework Schema Die Klassenstruktur sieht wie folgt aus. Der RPLidar ist hier nur ein Beispiel, für diesen existiert keine Implementiert. Klassestruktur

Programm

Das Konzept läuft wie folgt ab: Messdaten werden vom LiDAR ausgelesen, diese exstieren in Polarkoordinaten. Die Messung wird dann ersteinmal Vorverarbeitet. Der erste Schritt ist es diese Daten in ein karthesischen Koordinatensystem umzurechnen, dann werden diese in das Koordinatensystem des Fahrzeuges transformiert. Die Daten werden dann auf eine Region Of Interest (ROI) beschränkt. Die Daten sind dann bereit für die eigentliche Datenverarbeitung werden dann segmentiert, getrackt und über die RS232-Schnittstelle an die dSpace-Karte geschickt.

Messwerte

Auf Anfrage mit dem entsprechenden Befehl gibt der Laserscanner ein Array mit Messwerten zurück. Der Platz im Array entspricht dem Winkel, in dem der zugehörige Wert gemessen wurde. Der Wert entspricht der Entfernung in mm. Zu beachten ist, dass 1024 Werte des Laserscanners einer 360° Messung entsprechen. Die Messung beginnt am hinteren Ende des Sichtbereichs. Je nach Ausführung (auf Fahrzeug oder Testscanner) misst der Scanner dann im oder gegen den Uhrzeigersinn.

Ansatz zur Objekterkennung

Zur Objekterkennung wird die zweite Ableitung der Y-Position der Messwerte genutzt. Entlang einer Kante eines Objektes und wenn sich an einer Position kein Objekt befindet bleibt diese annähernd Null. An einer Außenkante besitzt die zweite Ableitung einen großen Wert, da sich die erste Ableitung stark ändert. Bei einer Kante innerhalb eines Objektes ändert sich die erste Ableitung weniger stark und so ist auch der Wert der zweiten Ableitung geringer. Dies ermöglicht es zwischen Innen- und Außenkanten zu unterscheiden. Bei einer detektierten Innenkante können somit der Winkel des Objektes und seine Tiefe berechnet werden.

Implementierung in C/C++

Es gibt ein allein lauffähiges Programm, welches zu Tests abseits vom Fahrzeug und zur Aufzeichnung von Messdaten genutzt werden kann. Dieses ist im SVN unter zu finden. Die einzelnen Verarbeitungsschritte sind durch Kommentare erklärt.

Implementierung auf Fahrzeug

Für die Ausführung auf dem Fahrzeug wurden die Objekterkennung mit Laserscanner, die Objekterkennung mit Kamera und die Spurerkennung mit Kamera in einem Programm zusammengeführt. Hierdurch muss keine Kommunikation zwischen den einzelnen Softwareteilen aufgebaut werden. Ebenso können die detektierten Objekte in das Videobild eingespeißt werden um sie so besser mit der Realität vergleichen zu können. Allerdings gibt es Probleme mit der Koordinatentransformation. Diese müssen noch behoben werden. Das kombinierte Programm ist unter zu finden. Die für die Objekterkennung relevanten Dateien sind hierbei LidarObject.h und LidarObject.cpp. Sie werden in der Hauptdatei SpurerkennungV01 genutzt. Die öffentlichen Funktionen sind hierbei Lidar_Init(), welche einmal pro Programmausführung aufgerufen werden muss um die Kommunikation mit dem Laserscanner zu initialisieren, sowie object_detection(), welche zyklisch aufgerufen wird. Diese liest die Daten vom Laserscanner, detektiert vorhandene Objekte und gibt die Objektliste zurück. Beim ersten Benutzen des Programms sollte folgendes beachtet werden:

Baudrate und Lidar-Port werden in der LidarObject.h definiert. Um den Port des Lidar herauszufinden kann man im Geräte-Manager von Windows unter Anschlüsse (COM & LPT) nach URG Series USB Device Driver suchen. Die Baudrate ist bei dem verwendeten Hokuyo URG-04LX 115200 Bit pro Sekunde.

=blauf der Objekterkennung

Konfigurierter Öffnungswinkel des Lidar (Originaldatei als XCF)

Zuerst werden die Rohdaten in ein Array geschrieben. Danach wird abhängig davon ob wir den Lidar mit USB Anschluss oder mit RS232 betreiben das define LIDAR_ONCAR genutzt, um das Array zu drehen (USB-Lidar dreht im Uhrzeigersinn, RS232-Lidar gegen Uhrzeigersinn). Danach wird der Winkel beschnitten, damit nicht alle Werte ausgelesen werden müssen. Momentan ist ein Winkel von 90 Grad senkrecht nach vorne konfiguriert. Auch werden Objekte ignoriert, die weiter als ein Meter vom Auto entfernt sind, da nur die unmittelbaren Hindernisse zu beachten sind. Dann kann die Datenauswertung zur Objektfindung beginnen. Nun werden benachbarte Punkte beim Lidar im Uhrzeigersinn miteinander verglichen. Wenn es einen Sprung von größer zwanzig Zentimeter zwischen zwei Punkten gibt, dann wird hier der Anfang eines Objektes definiert. Das Ende wird an den Punkt gesetzt, an dem der vorherige Punkt wieder eine Differenz von größer zwanzig Zentimetern besitzt. Nun werden alle Punkte vom Start- bis zum Endpunkt analysiert. Dazu wird der Punkt mit dem niedrigsten Abstand zum Lidar als Eckpunkt des Objektes genommen und mit dem Erhalt dieses Punktes können nun die Restlichen zu übergebenen Parameter mit Pythagoras berechnet werden. Dies sind der Winkel, die Breite und die Tiefe des Objektes. Die Plausibilität eines Objektes steigt mit der Anzahl von Punkten aus denen es besteht. Nun wird ein weiteres Objekt gesucht. Wenn alle Punkte analysiert worden sind, werden die erkannten Objektparameter an die Kommunikationsschnittstelle weitergegeben.

Ablaufplan der Lidar-Objekterkennung, die bei jeder Programmiteration aufgerufen wird (Originaldatei als Visio)

Objekterkennung und Tracking (WS2016/2017)

Lidar Objekterkennung und Tracking(Originaldatei)

Die Software für den Lidarsensor wurde in C/C++ in Visual Studio implementiert. Generell kann unterschieden werden zwischen Objekterkennung und dem Tracking. In jedem Zyklus werden in der Objekterkennung Objekte gebildet, welche nur aus Daten aus dem aktuellen Zylkus bestehen. Diese Objekte werden nachgehend dem Tracking zugeführt. In dem Tracking wird aus der Objektposition die Geschwindigkeit in X,- und Y Richtung bestimmt. Als Filter wird ein Alpha-Beta Filter [1] verwendet, welcher ähnlich dem Kalman Filter eine Prädiktion mit hinterlegtem Bewegungsmodell und eine Korrektur mit den aktuellen Messwerten durchführt. Als Bewegungsmodell wird hier ein Null-Beschleunigungsmodell zugrunde gelegt. Vorteile des Alpha-Beta Filters:

-Einfache Parameterisierung (Alpha und Beta)

-Einfache Umsetzung (keine Matrix Operationen in C++)

In den kommenden Semestern kann dieser Alpha-Beta filter gerne gegen einen konventionellen Kalman Filter getauscht werden,- die nötige Funktionsstruktur ist softwareseitig mit dem Alpha-Beta Filter bereits gegeben(Prädiktion, Zuordnung Objekt-Track, Korrektur der Prädiktion durch Messung).

Aus der Sicht des Authors ist dies allerdings nicht unbedingt nötig, da der Lidar Sensor schon sehr "saubere" Messwerte ausgibt.

Die Objekterkennung und das Tracking sind in der Datei LidarObject.cpp / LidarObject.h implementiert.

Durch das Projektteam im Wintersemester 2018/19 wurde der Ablageort des aktuellen Programms verschoben. Dieses befindet sich nun im Ordner
https://svn.hshl.de/svn/MTR_SDE_Praktikum/trunk/Software/Objekt_Spurerkennung/

Dort befindet sich das Visual Studio Projekt mit dem neuesten Lidar Tracking, als auch der neuesten Spurerkennung. (Die generierte EXE aus diesem Projekt sendet die Daten an die Dspace Karte, auf der das Simulink Modell läuft)

Die alten Vorgängerversionen dieser Software wurden in das Software-Archiv verschoben.

Lidar Objekterkennung und Tracking (unteres Fenster)(Originaldatei)

Visualisierung/Plot der Tracks

Neben der Objekterkennung wurde in der Datei LidarPlot.cpp/h eine Plotfunktionalität geschaffen.

Hier werden angezeigt:

- Rohziele des Lidarsensors

- Tracks mit IDs

- Track Eigenschaften (z.B. Vx, Vy,..)

Ausblick

• Die Objekte werden zur Zeit nur zyklisch gebildet. Der nächste Schritt, nachdem die Koordinatentransformation funktionsfähig ist, wird ein Objekttracking mit Datenfusion der LIDAR- und Kameraobjekte sein. Hierfür wird ein Kalman-Filter vorgeschlagen. Als Zuordnungsverfahren wäre z.B. ein Munkrest-Algorithmus empfehlenswert.
• Bei der hier vorgestellten Objekterkennung mit Lidar werden in kombinierter Nutzung mit dem Kommunikations- und Kamera-Algorithmus falsche Lidar-Rohdaten an die Objekterkennung weitergegeben. Dieser Fehler kennzeichnet sich durch die Verschiebung des Zeigers, welcher auf das Rohdaten-Array zeigt. Die Fehlerursache muss geklärt werden. Es kann ein Treiberproblem oder die Überlastung der Hardware der Grund sein, da eine Verbindung zwischen Häufigkeit des Fehlers und Auslastung des Systems festgestellt werden konnte.
• Eine weitere Korrektur die durchgeführt werden muss, ist eine Umpositionierung der Kamera oder/und des Lidar, so dass der Lidar sich bei der Aufnahme nicht im Kamerafenster befindet. Denn in engen Kurven würde bei installiertem Lidar momentan ein Teil der Fahrspurbegrenzung bedeckt werden, so dass die Spurführung nicht mehr sauber ausgeführt werden kann.

Autor: Stephan Maier Stefan Schauerte
Bearbeitet im WS18/19 von: Benedikt Wulowitsch

MATLAB Testumgebung

Zur Auswertung der Aufzeichnung und zum Test des Programms gibt es zwei MATLAB Skripte, die eine graphische Darstellung ermöglichen. Die nachfolgend beschriebenen Dateien sind im SVN unter zu finden.

Anzeigen der aufgezeichneten Messdaten

Das Skript ExportDataViewer.m erlaubt es die Aufzeichnungen aus den Textdateien des allein lauffähigen C-Programms einzulesen und darzustellen. Hierfür müssen die gewünschten zusammengehörigen Objekt- und Messaufzeichnungen ausgewählt werden. Die Ergebnisse werden dann zyklisch angezeigt. Der jeweilige Messzyklus wird in der Konsole von MATLAB ausgegeben.

Simulation von Messdaten

Im Skript Object_Simulation.m können beliebige Objekte erzeugt werden. Aus den angegebenen Objektmaßen und Positionen werden anschließend Messdaten des Laserscanners erzeugt und an die C-File zur Objekterkennung übergeben. Die Ergebnisse der Objekterkennung werden anschließend Ebenfalls angezeigt. Um C-Files mittels mex aufzurufen muss folgende Funktion dem C-Code hinzugefügt werden:

 void mexFunction( int nlhs, mxArray *plhs[],
                   int nrhs, const mxArray *prhs[])
 {
     double *inMatrix;               /* 1xN input matrix */
     size_t ncols;                   /* size of matrix */
     double *outMatrix;              /* output matrix */
     /* check for proper number of arguments */
     if(nrhs!=1) {
         mexErrMsgIdAndTxt("MyToolbox:arrayProduct:nrhs","One input required.");
     }
     if(nlhs!=1) {
         mexErrMsgIdAndTxt("MyToolbox:arrayProduct:nlhs","One output required.");
     }
 
     
     /* check if number of rows in first input argument is 1 */
     if(mxGetM(prhs[0])!=1) {
         mexErrMsgIdAndTxt("MyToolbox:arrayProduct:notRowVector","Input must be a row  vector.");
    }
    
    /* create a pointer to the real data in the input matrix  */
    inMatrix = mxGetPr(prhs[0]);
    /* get dimensions of the input matrix */
    ncols = mxGetN(prhs[0]);
    /* create the output matrix */
    plhs[0] = mxCreateDoubleMatrix(1,(mwSize)ncols,mxREAL);
    /* get a pointer to the real data in the output matrix */
    outMatrix = mxGetPr(plhs[0]);
    /* call the computational routine */
    object_detection(inMatrix,outMatrix,(mwSize)ncols);
 }

Diese ruft im letzten Schritt dann die eigentliche Funktion zur Objekterkennung auf. Anschließend muss die C-File mittels mex-Compiler kompiliert werden hierzu dient der Befehl:

 mex -g NameDerC-File.c

Eine Beispieldatei liegt im Ordner der MATLAB-Dateien als Object_detection.c vor.

Verarbeitung der Objektdaten und Ausweichmanöver (WS2016/2017)

Das folgende Kapitel erläutert die Verarbeitung der in der .exe erzeugten Objektdaten. In dem Block "Sollvorgabe mit Hindernis" werden zuerst die Parameter a,b und c des Spurpolynoms, sowie die x- und y-Koordinate der getrackten Objekte und die zurückgelegte Strecke seit dem Beginn des Programms mittels CCF-Bus eingelesen. Anschließend werden die Parameter a, b und c in der Funktion "Verif_SenKam" auf Plausibilität geprüft. Im nächsten Schritt werden die auf Plausibilität geprüften Parameter des Spurpolynoms, sowie die x- und y-Koordinaten in eine Matlab-Funktion zur Generierung des Hindernis-Bit eingegeben. In der Funktion wird geprüft, ob eines der Objekte auf dem Spurpolynom liegt. Dazu wird die jeweilige x-Koordinate in das Polynom eingesetzt und die y-Koordinate wird mit dem Ergebnis verglichen. Liegt die y-Koordinate direkt auf dem Spurpolynom oder in einem Fahrschlauch 10cm links oder rechts von dem Spurpolynom und ist der euklidische Abstand zum Objekt kleiner als 50cm, dann wird ein Hindernisbit gesetzt und als Ausgang der Funktion ausgegeben. Das Hindernisbit wird anschließend in den Datentyp Bool umgewandelt und an dem Ausgang zwei des Blocks herausgeführt. Zur Erzeugung des Offset's für den Überhol- bzw. Ausweichvorgang wird eine weitere Matlab-Funktion eingesetzt. Die Eingänge setzen sich aus der zurückgelegten Strecke und dem Hindernisbit zusammen. Wird das Hindernisbit gesetzt, dann wird ein Offset ausgegeben. Der Offset bleibt jedoch mindestens zwei zurückgelegte Meter gleich, bevor er wieder auf null gesetzt wird. Der Offset wird mit der Variable "BSFQuer_Querablage_Soll_o_H_f64" addiert und anschließend als "BSFQuer_Querablage_Soll_H_f64" aus dem Block geführt.

Vorsicht: Der Algorithmus wurde noch nicht mit dem Hauptmodell zusammengeführt. Im Ordner https://svn.hshl.de/svn/MTR_SDE_Praktikum/branches/LidarAnpassung_Software_CaroloCupFahrzeug kann die Implementierung jedoch gefunden werden.

Hindernis(Originaldatei)

Anmerkung: Die programmierte, hier beschrieben Funktion, wurde verfiziert und wird in naher Zukunft, sobald sich die aktuelle Online-Version der Software mit MATLAB 2013a starten lässt, dort eingebettet. Zudem wurden in die programmierten MATLAB-Funktionen Kommentare und jeweils ein Header eingefügt.

Autor: Stephan Maier Stefan Schauerte Autor Anmerkung: Benedikt Wulowitsch

Dynamische Hindernisse: Erkennung und Ausweichvorgang (WS2018/2019)

Programmablaufplan des Ausweichvorgangs

Im Wintersemester 18/19 wurde die bisherige Objekterkennung um das Ausweichen von dynamischen Objekten nach REQ10.2350 ergänzt. Es soll ein Objekt, welches sich mit maximal 0.6 m/s auf der eigenen Spur bewegt, erkannt und umfahren werden. In keinem Fall darf eine Kollision mit diesem Hindernis auftreten. Im ersten Schritt wurde ein Konzept als Programmablaufplan erstellt.

Konzept

Analog zur bisherigen Objekterkennung wird die vom Lidar-Sensor erzeugte Objektliste auf das nächste Objekt reduziert. Um das dynamische Objekt überholen zu können, muss die Differenzgeschwindigkeit ermittelt werden und gegebenfalls die eigenen Geschwindigkeit erhöht werden.

Sobald der Abstand zum Objekt weniger als 2.5 Meter beträgt, wird der Überholvorgang durch setzen eines Hindernisbits und Querablagen-Offsets eingeleitet. Außerdem wird die Sollgeschwindigkeit angepasst und ein Überhol-Timer gestartet, um den Überholvorgang gegebenfalls abzubrechen. Um das Objekt während des Überholvorgangs zu tracken, wird der Abstand zum Objekt mittels der an der Fahrzeugseite angebrachten Infrarotsensoren bestimmt und das Offset gegebenfalls an diesen Abstand angepasst.

Sobald der hintere IR-Sensor das Objekt nicht mehr erfasst gilt der Überholvorgang als abgeschlossen und das Fahrzeug schert durch Löschen des Offsets und Hindernisbits wieder ein. Des Weiteren wird die Sollgeschwindigkeit wieder auf den normalen Wert verringert.

Sollte der Überholvorgang nicht in einer gewissen Zeit möglich sein, beispielsweise weil das Objekt beschleunigt, läuft der Überhol-Timer ab und der Überholvorgang wird abgebrochen. Die Sollgeschwindigkeit wird dabei solange verringert, bis das Objekt nicht mehr von den IR-Sensoren erkannt wird. Anschließend schert das Fahrzeug wieder ein.

Umsetzung in Simulink & Stateflow

Umgesetzt wurde das Konzept in Simulink und als Stateflow-Zustandsautomat.

Implementierung in Simulink

Wie die im vorherigen Kapitel beschriebene Implementierung für statische Hindernisse ist auch diese im Block "Sollvorgabe mit Hindernis" zu finden.

Hier befindet sich auch der Stateflow-Zustandsautomat, welcher einige Werte übergeben bekommt. Die gemessenen Abstände der Infrarotsensoren werden als "IR_VR" und "IR_HR" eingelesen. Übernommen wurde die eigentliche Abstandsberechnung, welche den Abstand zum nächsten Objekt der Lidar-Objektliste euklidisch berechnet, um auch in Kurven den korrekten Abstand zu ermitteln. Außerdem wird die Sollgeschwindigkeit eingelesen sowie der Zähler, welcher für die Berechnung der Überhol-Timers benutzt wird.

Ausgegeben wird wiederum das Hindernisbit sowie das Offset, welches mit der Variable "BSFQuer_Querablage_Soll_o_H_f64" addiert wird zur "BSFQuer_Querablage_Soll_H_f64".

Berechnung des euklidischen Abstands zum nächsten Objekt

Der Stateflow-Zustandsautomat wurde analog zum Programmablaufplan des Konzepts implementiert und stellt dessen Ablauffolge als eine Reihe von Zuständen dar.

Implementierung in Stateflow als Zustandsautomat

Anmerkung: Die Implementierung wurde im Branch 2018_12_14_Dynamische_Hindernisse durchgeführt, kann aber bei Bedarf mit dem Trunk zusammengeführt werden.

Ausblick

Bis zum Ende des Wintersemesters 18/19 konnten nicht alle Teile des Konzepts umgesetzt werden. Folgendes muss noch implementiert werden:

• Die Berechnung der Differenzgeschwindigkeit
• Die Anpassung der Sollgeschwindigkeit auf Basis der Differenzgeschwindigkeit. Hierfür kann der ebenfalls im WS18/19 realisierte Schalter Schalter_VxVorgabeHindernis (weitere Informationen) benutzt werden.
• Test der Implementierung mit dynamischen Hindernissen in der Simulation und im Online-Modus

Autor: Leon Hundertmark

Zusammenfassung

Die Rohdaten des Lidar werden wie gefordert ausgewertet und in eine Objektliste eingetragen. Im folgendem Punkt Ausblick sind einige Punkte gelistet, welche in den folgenden Semestern bearbeitet werden sollten.

Softwaretest im WS2018/2019

Während des Wintersemesters 2018/2019 wurde die hier vorgestellte Software in Bezug auf Aktualität und Funktion geprüft. Die aktuellste Software, welche auch zum aktuellen Zeitpunkt auf dem Auto lauffähig ist, wurde im SVN-Ordner dieses Praktikums unter /Software/Objecterkennung_Spurerkennung abgelegt.
Die alten Versionen, welche vom Vorsemester entwickelt wurden, befinden sich nun im Ordner Software/Archiv.
Nach dem grundsätzlichen Funktionstest der Kamera und des LIDAR mit der Herstellersoftware begann der eigentliche Softwaretest.
Festzustellen war, dass die Software ohne angeschlossenen LIDAR sehr langsam läuft und so nicht brauchbar ist. Weiterhin wurde in dem Programm eine Laufzeitmessung eingeführt, welches die Laufzeit eines Programmloops auf der Konsole ausgibt.
Das Ergebnis dieser Laufzeitmessung ist in der nachfolgenden Abbildung dargestellt.

Ermittlung der Laufzeit des C-Programms

Diese Laufzeit beschreibt die reine Laufzeit des C-Programms, eine Laufzeitmessung der seriellen Schnittstelle zur Feststellung der Übertragungsgeschwindigkeit zur dSpace-Karte findet in der Zukunft statt.

Um die Laufzeit zu ermitteln, wurde zum Startpunkt und zum Endpunkt des Programms ein Zeitstempel gesetzt. Nach dem setzten des zweiten Zeitstempels wurde die Differenz zwischen Endzeit und Startzeit gebildet. Diese Differenz in Millisekunden gibt die Zeit an, die das C-Programm benötigt um einen Programmdurchlauf zu absolvieren.

Zu Beginn des Tests wurden Untersuchungen angestellt, welches Programm nun das aktuellste ist und die versprochene Funktion liefert.
Nachdem die aktuellste Version ausgemacht wurde, wurde das Programm mit dem zweiten Auto getestet. Hierfür wurde das Fahrzeug lokal an einen Computer angeschlossen und die Inbetriebnahme der Softwar erfolgte.
Die nachfolgende Abbildung zeigt das verkabelte Auto vor einem Hinderniss.

Verkabeltes Testauto

Aufbauend auf das verkabelte Auto vor dem Hinderniss, wurde das C-Programm der Vorsemester gestartet. Die Bildschirmausgabe zeigt die nachfolgende Abbildung.

Bildschirmausgabe des C-Programms zur Objekterkennung

In der Bildschirmausgabe ist auf der rechten Seite das Kamerabild dargestellt. Hierbei ist gut das Hinderniss in Form einer Kiste dargestellt. Zudem wird die rechte Fahrbahnmarkierung erkannt und mit roten Punkten dargestellt.
Mittig des Bildes ist das Ausgabefenster des LIDAR dargestellt. Hierbei wird mit einer blauen Linie innerhalb des roten Rahmens das Objekt (Kiste) erkannt. Zudem wird ein Abstand vom Lidar bis zum objekt und eine Objektbreite angegeben.
Oben links in der Abbildung ist die Ausgabekonsole des C-Programm geöffnet. Hier werden beispielsweise die Spurparameter ausgegeben, welche die aktuelle Spur (rote Punkte auf rechter Bildseite) abbilden. Es werden zu diesen Parameter auch die Anzahl der Punkte die Anzahl der gedroppten Frames ausgegeben. Solange ein LIDAR angeschlossen ist, ist die Anzahl der gedroppten Frames im kleinen, einstelligen Bereich. Ist der LIDAR nicht in Betrieb, so steigt die Anzahl der gedroppten Frames auf ca. 25 an und das Programm ist Quasi unbrauchbar.

Hiermit gilt dieser Test als abgeschlossen, sodass das Fahrzeug nun in der Lage ist die Fahrbahnmarkierungen korrekt zu erkennen und ein Polynom zu bilden. Weiterhin ist es dem Fahrzeug möglich Objekte zu erkennen, in eine Objektliste einzutragen und die Breite und Entfernung zum Objekt zu bestimmen.

Lidar wird als Maus erkannt

Im Wintersemester 2018/19 ist aufgefallen, dass nach einer Programmlaufzeit von ca. 10 Minuten der Lidar als Maus erkannt wird. Es werden wahrlos Fenster geöffnet und Verknüpfungen erstellt. Das Problem wird temporär behoben, indem das USB-Kabel zwischen Lidar und PC getrennt wird. Dieses Problem tritt sowohl beim CaroloCup-Fahrzeug, als auch bei dem PC's im Labor Autonome Systeme auf. In der nachfolgenden Abbildung ist der Desktop des PC's im Labor dargestellt, während der Lidar als Maus erkannt wurde. Es ist dem Bild gut zu entnehmen, dass unmengen an Verknüpfungen erstellt wurden.

Lidar wird als Maus erkannt

Autor: Benedikt Wulowitsch, John Kneib

Literatur

---

→ zurück zum Hauptartikel: Praktikum SDE
→ zurück zu OSE - Objekt - und Spurerkennung