Objekterkennung mit Laserscanner: Unterschied zwischen den Versionen

Aus HSHL Mechatronik
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
 
(41 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt)
Zeile 3: Zeile 3:
→ zurück zu [[OSE - Objekt - und Spurerkennung|OSE - Objekt - und Spurerkennung]]
→ zurück zu [[OSE - Objekt - und Spurerkennung|OSE - Objekt - und Spurerkennung]]
----
----
'''Autor:''' [[Benutzer:Michael_Deitel|Michael Deitel]] [[Benutzer:Manuel_Gross|Manuel Groß]]  
'''Autor:''' [[Benutzer:Michael_Deitel|Michael Deitel]] [[Benutzer:Manuel_Gross|Manuel Groß]] <br />
'''Bearbeitet von:''' [[Benutzer:Patricio-emiliano hernandez-murga|Patricio Emiliano Hernandez Murga]] und [[Benutzer:Moritz-Ben-Joe Kühnrich|Moritz-Ben-Joe Kühnrich]]


== Einleitung ==
== 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 [[Benutzer:Michael_Deitel|Michael Deitel]] und [[Benutzer:Manuel_Gross|Manuel Groß]] bearbeitet. Die Vorarbeit zu diesem Thema wurde von [[Benutzer:Jens Ruhrlaender|Jens Ruhrlaender]] geleistet.
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 [[Benutzer:Michael_Deitel|Michael Deitel]] und [[Benutzer:Manuel_Gross|Manuel Groß]] bearbeitet. Die Vorarbeit zu diesem Thema wurde von [[Benutzer:Jens Ruhrlaender|Jens Ruhrlaender]] geleistet. Das Thema wird im Wintersemester 2022/2023 von [[Benutzer:Patricio-emiliano hernandez-murga|Patricio Emiliano Hernandez Murga]] und [[Benutzer:Moritz-Ben-Joe Kühnrich|Moritz-Ben-Joe Kühnrich]] neu aufgerollt.


== Inhalt ==
== Inhalt ==
Zeile 15: Zeile 16:
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).
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).


Es ist zu beachten, dass der nicht verbaute Laserscanner neben der USB-Schnittstelle, die auch der auf dem Fahrzeug befindliche Scanner hat, einen RS232 Anschluss besitzt. Bei dieser Version wird die Stromversorgung über bestimmte Pins an der RS232 Schnittstelle gewährleistet. Hierfür wurde ein Adapterkabel angefertigt, um die Stromversorgung über einen zweiten USB-Anschluss am PC zu verwirklichen. Es müssen also beide USB-Kabel für den Betrieb angeschlossen werden.  
Beim erstmaligen Anschluss werden die Treiber nicht automatisch installiert. Diese müssen manuell eingebunden werden. Die Treiber sind im SVN unter <ref> ''trunk\Dokumentation\Datenblätter\Laserscanner\URG Driver for Win'' im SVN-Archiv</ref>


Beim erstmaligen Anschluss werden die Treiber nicht automatisch installiert. Diese müssen manuell eingebunden werden. Die Treiber sind im SVN unter <ref> ''trunk\Dokumentation\Datenblätter\Laserscanner\URG Driver for Win'' im SVN-Archiv</ref>  zu finden. Eine genaue Beschreibung hierfür und zum Einbinden der URG-Bibliothek für die Kommunikation mit dem Laserscanner über C/C++ hat Asaad Al-Suleihi angefertigt. Sie ist zu finden unter <ref> ''trunk\Dokumentation\Datenblätter\Laserscanner\Anleitung_Laserscanner_URG-04XL-UG01 im SVN-Archiv'' </ref>.
Um den LiDAR dann über C/C++ zu verwenden muss die dazugehörige URG-Bibliothek eingebunden werden. Eine detaillierte Anleitung dafür befindet sich [https://svn.hshl.de/svn/MTR_SDE_Praktikum/trunk/Software/Laserscanner/WS2022/LiDAR_Framework/LiDAR_Framework.chm hier]


=== Programm ===
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:


====Messwerte====
'''REQ10.2330:'''<br />
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.
1. Erkennung von statischen Hindernissen<br />
===Ansatz zur Objekterkennung===
2. Zu erkennende Hindernisse haben eine Feste Abmessung (Pappkartons 31cm x 22cm)<br />
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.
3. Erkennung der Position der Hindernissen<br />
====Implementierung in C/C++====
'''REQ10.2350:'''<br />
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 <ref>''trunk\Software\Laserscanner\Laserscanner_Testprogramme\laser_continuous_mode''</ref> zu finden. Die einzelnen Verarbeitungsschritte sind durch Kommentare erklärt.
4. Erkennung von dynamischen Hindernissen<br />
5. Erkennung der Geschwindigkeit der dynamischen Hindernissen<br />
6. Erkennung der Orientierung der Boxen<br />
'''REQ10.3170:'''<br />
7. Lernen des Rundkurses<br />
'''Aus der Kommunikation und Rücksprache mit anderen Gruppen:'''<br />
8. Errechnung eines Vertrauenswert für die Objekte


====Implementierung auf Fahrzeug====
===funktionaler Systementwurf===
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 <ref>''trunk\Teams\OSE\OSE_Wiegand_Salinski\Objekt_Spurerkennung\Objekt_Spurerkennung\Objekt_Spurerkennung\Module\lidar''</ref> 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:
Hier wird der grobe Ablauf des LiDAR-Systems gezeigt<br /><br />


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.
1. Einlesen der LiDAR-Daten<br />
2. Erkennung der Boxen aus den Daten<br />
3. Tracking der Boxen<br />
4. Weitersenden an die dSPACE-Karte<br /><br />


====Ablauf der Objekterkennung====
===Technischer Systementwurf===
[[Datei:LidarRange.png|mini|400px|Konfigurierter Öffnungswinkel des Lidar [[:Datei:LidarRange_Quelle.zip |(Originaldatei als XCF)]]]]
Hier wird der eben funktionale Systementfwurd weiter ausgeführt.</br>
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.
[[Datei:LiDAR technischer systementwurf.png|200px|Klassestruktur]]</br></br>
[[Datei:Objekterkennung.png|mini|links|600px||Ablaufplan der Lidar-Objekterkennung, die bei jeder Programmiteration aufgerufen wird [[:Datei:Objekterkennung.vsdx |(Originaldatei als Visio)]]]]
<div style="clear:both"></div>


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


==== Objekterkennung und Tracking (WS2016/2017) ====
===Komponenten Spezifikationen===
====Einlesen der Daten====
Für das Einlesen der LiDAR-Daten wurde eigenes Framework entwickelt. Dieses ist weiter unten im Artikel dokumentiert


[[Datei:Lidar Objekterkennung und Tracking.png|thumb|400px|mitte|Lidar Objekterkennung und Tracking[[:Datei:Lidar Objekterkennung und Tracking.png|(Originaldatei)]]]]
====Segmentierung====
'''Eingang:'''</br>
- LiDAR-Daten</br>
'''Ausgang:'''</br>
- 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.</br>
'''Einzustellende Parameter:'''</br>
- Minimale Punktanzahl pro Segment</br>
- Maximaler Abstand zwischen zwei Punkten des Segments</br>
- Filterung des Nahbereichs wegen der Reflektion an der Sensorkappe</br>
'''Ablauf:'''</br>
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.</br>
====Objektbildung====
'''Eingang:'''</br>
- L-Shapes</br>
'''Ausgang:'''</br>
- Objektliste</br>
'''Einzustellende Parameter:'''</br>
- Prozentuale Abweichung des Winkels zwischen zwei Schenkeln, damit das L-Shape als Box mit zwei sichtbaren Seiten erkannt wird</br>
- Schwellwert für den Winkel, damit das L-Shape als eine Linie behandelt wird</br>
- Abweichung der Abmessung damit L-Shape noch als Box gewertet wird</br>
- Vertrauenswert-Abzüge falls Tiefe, Breite oder Winkel nicht aus dem L-Shape ermittelbar sind</br>
'''Ablauf:'''</br>
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.
</br>
====Tracking====
'''Eingang:'''</br>
- ObjektListe</br>
'''Ausgang:'''</br>
- Trackliste</br>
'''Einzustellende Parameter:'''</br>
- Distanz zum Gating zwischen einer Box aus dem letzten Frame und dem aktuellen Frame</br>
- Maximale Strikes die ein Track haben darf, bevor es rausfliegt</br>
- TP-alpha für die Position</br>
- TP-alpha für die Ausrichtung</br>
'''Ablauf:'''</br>
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.
</br>
===Implementierung===
Die Funktionen Segmentierung, Objektbildung wurden alle in Matlab implementiert und dann mit dem Matlab-Coder zu C-Code exportiert. </br>
[https://svn.hshl.de/svn/MTR_SDE_Praktikum/trunk/Software/Laserscanner/WS2022/Matlab_Sim/Release/ObjektBildung_SEF.m Segmentierung und Objektbildung]</br>
[https://svn.hshl.de/svn/MTR_SDE_Praktikum/trunk/Software/Laserscanner/WS2022/Matlab_Sim/Release/Tracking.m Tracking]</br></br>


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


Die Software für den Lidarsensor wurde in C/C++ in Visual Studio implementiert.
===Modultest===
Generell kann unterschieden werden zwischen Objekterkennung und dem Tracking.
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:</br>
In jedem Zyklus werden in der Objekterkennung Objekte gebildet, welche nur aus Daten aus dem aktuellen Zylkus bestehen.
[https://svn.hshl.de/svn/MTR_SDE_Praktikum/trunk/Software/Laserscanner/WS2022/Matlab_Sim/Release/teste_objBildunhg.m Modultest-Segmentierung und Objektbildung]</br>
Diese Objekte werden nachgehend dem Tracking zugeführt.
[https://svn.hshl.de/svn/MTR_SDE_Praktikum/trunk/Software/Laserscanner/WS2022/Matlab_Sim/Release/testeTracking.m Modultest-Tracking]</br>
In dem Tracking wird aus der Objektposition die Geschwindigkeit in X,- und Y Richtung bestimmt.
[https://svn.hshl.de/svn/MTR_SDE_Praktikum/trunk/Software/Laserscanner/WS2022/Matlab_Sim/Release/LiDAR_Umgebung.m Gesamt-Testmodul]</br>
Als Filter wird ein Alpha-Beta Filter [https://en.wikipedia.org/wiki/Alpha_beta_filter] verwendet, welcher ähnlich dem Kalman Filter eine Prädiktion mit hinterlegtem Bewegungsmodell und eine Korrektur mit den aktuellen Messwerten durchführt.
</br></br>
Als Bewegungsmodell wird hier ein Null-Beschleunigungsmodell zugrunde gelegt.
Der generierte Code wurde in die Visual-Studio-Projektmappe [https://svn.hshl.de/svn/MTR_SDE_Praktikum/trunk/Software/Laserscanner/WS2022/LiDAR_Framework LiDAR-Framework] eingefügt. Dieses C-Projekt wurde mit Doxygen dokumentiert.
Vorteile des Alpha-Beta Filters:


-Einfache Parameterisierung (Alpha und Beta)
===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 </br>
[[Datei:Framework.png|500px|LiDAR-Framework Schema]]
</br>
Die Klassenstruktur sieht wie folgt aus. Der LidarA1M8 ist hier nur ein Beispiel, für diesen existiert keine Implementierung.
</br>
[[Datei:Polymorphie.png|500px|Klassestruktur]]</br>


-Einfache Umsetzung (keine Matrix Operationen in C++)
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 [https://svn.hshl.de/svn/MTR_SDE_Praktikum/trunk/Software/Laserscanner/WS2022/LiDAR_Framework/LiDAR_Framework.chm Doxygen-Dokumentation] zu finden!


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).
=== 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.


Aus der Sicht des Authors ist dies allerdings nicht unbedingt nötig, da der Lidar Sensor schon sehr "saubere" Messwerte ausgibt.
'''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.


''Die Objekterkennung und das Tracking sind in der Datei LidarObject.cpp / LidarObject.h implementiert.''
[[Datei:HindernissUmfahrung.JPG|thumb|800px|mitte|Hindernis[[:Datei:HindernissUmfahrung.JPG|(Originaldatei)]]]]


Durch das Projektteam im Wintersemester 2018/19 wurde der Ablageort des aktuellen Programms verschoben. Dieses befindet sich nun im Ordner  <br>
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.
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.
(Die generierte EXE aus diesem Projekt sendet die Daten an die Dspace Karte, auf der das Simulink Modell läuft)
Zudem wurden in die programmierten MATLAB-Funktionen Kommentare und jeweils ein Header eingefügt.


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


[[Datei:Lidar_screenshot.jpg|thumb|300px|mitte|Lidar Objekterkennung und Tracking (unteres Fenster)[[:Datei:Lidar_screenshot.jpg|(Originaldatei)]]]]


'''Autor:''' [[Benutzer:Stephan_Maier|Stephan Maier]] [[Benutzer:Stefan_Schauerte|Stefan Schauerte]]
'''Autor Anmerkung:'''  [[Benutzer:Benedikt_Wulowitsch|Benedikt Wulowitsch]]




'''Visualisierung/Plot der Tracks'''  
=== 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'''
[[Datei:PAP_dynamisch_Objekte.png|thumb|250px|rechts|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.


Neben der Objekterkennung wurde in der Datei LidarPlot.cpp/h eine Plotfunktionalität geschaffen.  
==== 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.


Hier werden angezeigt:
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.


- Rohziele des Lidarsensors
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.


- Tracks mit IDs
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.


- Track Eigenschaften (z.B. Vx, Vy,..)
==== Umsetzung in Simulink & Stateflow ====
Umgesetzt wurde das Konzept in Simulink und als Stateflow-Zustandsautomat.




[[Datei:DynHind_Simulink.png|mini|zentriert|700px|Implementierung in Simulink]]




Wie die im [[Objekterkennung mit Laserscanner#Verarbeitung der Objektdaten und Ausweichmanöver (WS2016/2017)|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".




[[Datei:DynHind_Abstand.png|mini|zentriert|700px|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.




[[Datei:DynHind_Stateflow.png|mini|zentriert|600px|Implementierung in Stateflow als Zustandsautomat]]




'''Anmerkung:''' Die Implementierung wurde im Branch [https://svn.hshl.de/svn/MTR_SDE_Praktikum/branches/2018_12_14_Dynamische_Hindernisse/ 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''' ([[BSF - Bahn- und Spurführung#Längsregelung Wintersemester 2018/19|weitere Informationen]]) benutzt werden.
* Test der Implementierung mit dynamischen Hindernissen in der Simulation und im Online-Modus




'''Autor:''' [[Benutzer:Leon_Hundertmark|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.<br>
Die alten Versionen, welche vom Vorsemester entwickelt wurden, befinden sich nun im Ordner Software/Archiv.<br>
Nach dem grundsätzlichen Funktionstest der Kamera und des LIDAR mit der Herstellersoftware begann der eigentliche Softwaretest.<br>
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.<br>
Das Ergebnis dieser Laufzeitmessung ist in der nachfolgenden Abbildung dargestellt.
<br>
[[Datei:Ermittlung_Laufzeit.PNG|mini|zentriert|800px|Ermittlung der Laufzeit des C-Programms]]
<br>
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.<br>


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. <br>
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.<br>
Die nachfolgende Abbildung zeigt das verkabelte Auto vor einem Hinderniss.<br>


[[Datei:Auto_Verkabelt.PNG|mini|zentriert|800px|Verkabeltes Testauto]]<br>




<br>


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


'''Autor:''' [[Benutzer:Stephan_Maier|Stephan Maier]] [[Benutzer:Stefan_Schauerte|Stefan Schauerte]] <br>
'''Bearbeitet im WS18/19 von:''' [[Benutzer:Benedikt Wulowitsch|Benedikt Wulowitsch]]


===MATLAB Testumgebung===
[[Datei:Auto_auf_Fahrbahn_mit_Hindernis.PNG|mini|zentriert|1000px|Bildschirmausgabe des C-Programms zur Objekterkennung]]<br>


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 <ref>''trunk\Software\Laserscanner\Matlab''</ref> zu finden.
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.<br>
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.<br>
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. <br>


====Anzeigen der aufgezeichneten Messdaten====
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.


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.


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


[[Datei:Bug_VR-Kamera_wird_als_Maus_erkannt.PNG|mini|zentriert|800px|Lidar wird als Maus erkannt]]<br>


====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.
'''Autor:''' [[Benutzer:Benedikt Wulowitsch|Benedikt Wulowitsch]], [[Benutzer:John Kneib|John Kneib]]
Um C-Files mittels mex aufzurufen muss folgende Funktion dem C-Code hinzugefügt werden:
<syntaxhighlight lang="c" style="background-color: #EFF1C1">
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);
}
</syntaxhighlight>
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:
<syntaxhighlight lang="c" style="background-color: #EFF1C1>
mex -g NameDerC-File.c
</syntaxhighlight>
Eine Beispieldatei liegt im Ordner der MATLAB-Dateien als ''Object_detection.c'' vor.


=== Verarbeitung der Objektdaten & 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.
[[Datei:HindernissUmfahrung.JPG|thumb|800px|mitte|Hindernis[[:Datei:HindernissUmfahrung.JPG|(Originaldatei)]]]]
'''Autor:''' [[Benutzer:Stephan_Maier|Stephan Maier]] [[Benutzer:Stefan_Schauerte|Stefan Schauerte]]
== 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.
== 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.
#Für dynamische Objekte, welche sich im Raum bewegen (beispielsweise andere Fahrzeuge) muss von der Auswertung der Daten noch ein Geschwindigkeitsvektor für jedes Objekt ermittelt und in die Objektliste eingetragen werden.
== 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.
== Literatur ==
== Literatur ==
<references />
<references />
== Korrektur/Rückmeldungen ==


----
----
→ zurück zum Hauptartikel: [[Praktikum_SDE|Praktikum SDE]] <br />
→ zurück zum Hauptartikel: [[Praktikum_SDE|Praktikum SDE]] <br />
→ zurück zu [[OSE - Objekt - und Spurerkennung|OSE - Objekt - und Spurerkennung]]
→ zurück zu [[OSE - Objekt - und Spurerkennung|OSE - Objekt - und Spurerkennung]]

Aktuelle Version vom 6. Dezember 2022, 21:11 Uhr

→ 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 [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.
Klassestruktur

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
LiDAR-Framework Schema
Die Klassenstruktur sieht wie folgt aus. Der LidarA1M8 ist hier nur ein Beispiel, für diesen existiert keine Implementierung.
Klassestruktur

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.

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)

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

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

Lidar wird als Maus erkannt



Autor: Benedikt Wulowitsch, John Kneib

Literatur

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

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