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.

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 ^[1]

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

Bei der Entwicklung des LiDARs ist nach ne V-Modell vorgegangen worden.

Anforderungen

Aufgrund der Requirements im Lastenheft des Praktikums ergeben sich für das LiDAR-System folgenden Anforderungen:

REQ10.2330:
1. Erkennung von statischen Hindernissen
2. Zu erkennende Hindernisse haben eine Feste Abmessung (Pappkartons 31cm x 22cm)
3. Erkennung der Position der Hindernissen
REQ10.2350:
4. Erkennung von dynamischen Hindernissen
5. Erkennung der Geschwindigkeit der dynamischen Hindernissen
6. Erkennung der Orientierung der Boxen
REQ10.3170:
7. Lernen des Rundkurses
Aus der Kommunikation und Rücksprache mit anderen Gruppen:
8. Errechnung eines Vertrauenswert für die Objekte

funktionaler Systementwurf

Hier wird der grobe Ablauf des LiDAR-Systems gezeigt

1. Einlesen der LiDAR-Daten
2. Erkennung der Boxen aus den Daten
3. Tracking der Boxen
4. Weitersenden an die dSPACE-Karte

Technischer Systementwurf

Hier wird der eben funktionale Systementfwurd weiter ausgeführt.

1. Die LiDAR-Daten werden ausgelesen, diese werden dann in Polar-Koordinaten ausgeben
2. Die LiDAR Punkte werden mithilfe eines Sucessive Edge Following(SEF) Algorithmus segmentiert. Es entstehen L-Shapes
3. Die Segmente werden gefiltert, sodass nur L-Shapes verarbeitet werden, Diese werden zu Objekte verarbeitet
4. Die Objekte sollen getrackt und gefiltert werden
5. Die 5 wichtigsten Objekte werden über die RS-232 Schnittstelle an die dSpace-Karte geschickt

Komponenten Spezifikationen

Einlesen der Daten

Für das Einlesen der LiDAR-Daten wurde eigenes Framework entwickelt. Dieses ist weiter unten im Artikel dokumentiert

Segmentierung

Eingang:
- LiDAR-Daten
Ausgang:
- Liste aus L-Shapes, ein L-Shape ist dabei ein Struct, bestehend aus: ID und dem linkesten Punkt, dem rechtesten Punkt und dem nächsten Punkt.
Einzustellende Parameter:
- Minimale Punktanzahl pro Segment
- Maximaler Abstand zwischen zwei Punkten des Segments
- Filterung des Nahbereichs wegen der Reflektion an der Sensorkappe
Ablauf:
In der Segmentierung sollen die LiDAR Daten segmentiert mithilfe eines Successive Edge Following Algorithmus zu L-Shapes und diese werden auf das Fahrzeug-Koordinatensystem umgerechnet werden.

Objektbildung

Eingang:
- L-Shapes
Ausgang:
- Objektliste
Einzustellende Parameter:
- Prozentuale Abweichung des Winkels zwischen zwei Schenkeln, damit das L-Shape als Box mit zwei sichtbaren Seiten erkannt wird
- Schwellwert für den Winkel, damit das L-Shape als eine Linie behandelt wird
- Abweichung der Abmessung damit L-Shape noch als Box gewertet wird
- Vertrauenswert-Abzüge falls Tiefe, Breite oder Winkel nicht aus dem L-Shape ermittelbar sind
Ablauf:
Die Objektbildung filtert alle L-Shapes die als Box in Frage kommen. Dabei wird unterschieden ob das L-Shape eine Linie darstellt oder eine zwei Seiten einer Box. Dies geschieht über den Winkel der zwei Schenkel des L-Shapes. Daraufhin wird überprüft die Abmessungen des L-Shapes mit dene einer Box übereinstimmen, wenn nicht, dann wird das Objekt verworfen. Je nachdem wie viel von der Box zu sehen sind und anhand der Geometrie wird dann ein Vertrauenswert errechnet.

Tracking

Eingang:
- ObjektListe
Ausgang:
- Trackliste
Einzustellende Parameter:
- Distanz zum Gating zwischen einer Box aus dem letzten Frame und dem aktuellen Frame
- Maximale Strikes die ein Track haben darf, bevor es rausfliegt
- TP-alpha für die Position
- TP-alpha für die Ausrichtung
Ablauf:
Im Tracking sollen erst die aktuelle Objekt der Trackliste zugeordnet werden, dann werden mit einem euklidischen Gating neue Objekte identifiziert, sowie Objekt die in der Trackliste stehen im aktuellen Frame aber nicht mehr zu sehen sind. Diese Tracks erhalten dann einen Strike, falls eine Objekt mehr Strikes als zugelassen hat, fliegt es aus der Trackliste raus. Neue Objekte werden der Trackliste hinzugefügt. Auf die getrackten Objekte wird dann die Position und die Ausrichtung mit einem Tiefpassfilter gefilter.

Implementierung

Die Funktionen Segmentierung, Objektbildung wurden alle in Matlab implementiert und dann mit dem Matlab-Coder zu C-Code exportiert.
Segmentierung und Objektbildung
Tracking

Der Code-Export ist aufwendig, deshalb sollte möglichst alle Fehler beseitigt werden bevor man Matlab-Code Exportiert

Modultest

Für alle Module gibt es eine eigenes Testmodul. Zusätzlich gibt es auch ein Testmodul für das Gesamtkonzept. In den jeweiligen Testmodulen ist es möglich sowohl einzelne Frames diverser Testmessungen durchzugehen, als auch ein Live-Visualisierung. Das Gesamt-Testmodul kann zusätzlich direkt mit dem LiDAR arbeite, dafür muss der Parameter für den COM-Port in der Funktion "sweepLidar" angepasst werden. Umschalten zwischen den Modi ist möglich über eine Schaltvariable in dem Gesamt-Testmodul. Die Testmodule sind hier zu finden:
Modultest-Segmentierung und Objektbildung
Modultest-Tracking
Gesamt-Testmodul

Der generierte Code wurde in die Visual-Studio-Projektmappe LiDAR-Framework eingefügt. Dieses C-Projekt wurde mit Doxygen dokumentiert.

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

Die Klassenstruktur sieht wie folgt aus. Der LidarA1M8 ist hier nur ein Beispiel, für diesen existiert keine Implementierung.

Es wurde auch ein LiDAR-Simulationsobjekt erstellt. Um einen weiteren LiDAR einzupflegen muss lediglich die virtuelle Klasse "Sensor-Lidar" implementiert werden. Weiteres ist in der Doxygen-Dokumentation zu finden!

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

Dieser Teil ist veraltetet, jedoch exisitert es noch um bei der Implementierung des Ausweichmanövers zu unterstützen 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.

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)

Dieser Teil ist veraltetet, jedoch exisitert es noch um bei der Implementierung des Ausweichmanövers zu unterstützen

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.

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

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

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.

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.

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

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 (WS2018/2019)

Ein Effekt der vom Team WS2022/2023 nicht bestätig werden kann 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.

Autor: Benedikt Wulowitsch, John Kneib

Literatur

↑ trunk\Dokumentation\Datenblätter\Laserscanner\URG Driver for Win im SVN-Archiv