Entwicklung einer echtzeitfähigen Applikation zur automatisierten Erkennung von Fahrzeuglichtfunktionen

Aufgabenstellung

• Stand der Technik Bildverarbeitung und Lichtfunktionen
• Untersuchungen zu Funktionsgrenzen mobiler Endgeräte bei der quantitativen Analyse
• Entwicklung eines Funktionsprototypen auf Basis eines mobilen Endgerätes
• Verifizierung an verschiedenen Fahrzeugmodellen

• Einleitung

  Die Prüfung der Fahrzeuglichtfunktionen im Speziellen ist in der StVZO (Anlage VIIIa: Durchführung der Hauptuntersuchung, Abschnitt 6.4.1 Aktive lichttechnische Einrichtungen) geregelt. Zur besseren Übersicht haben die Prüforganisationen eine Broschüre herausgegeben, welche die aktuellen Regelungen der StVZO, aber auch die harmonisierten Vorschriften der EU zusammen fassend und auf die praktische Anwendung bezogen enthält:

  [table id=6 /]

  Die Untersuchung der Fahrzeuglichter findet durch einen Prüfer bzw. Prüfingenieurstatt. Dabei beschränkt sich die Prüfung bei serienmäßiger Ausstattung, also wenn keine offensichtlichen Umbauten vorgenommen wurden, die einer ausführlichen Prüfung bedürfen (Einhaltung von Abstrahlwinkeln usw.) der Fahrzeuge auf folgende Punkte:
  1. Funktionstüchtigkeit der Leuchtmittel
  2. Lichtstärke auf beiden Seiten gleichmäßig
  3. Farben nach Regelwerk (siehe Tabelle)
  4. Blinkfrequenz der Fahrtrichtungsanzeiger
  5. Scheinwerfereinstellung

  [table id=7 /]

  Ziel ist die prototypische Entwicklung und Evaluierung einer automatischen Erkennung von Fahrzeuglichtfunktionen für die gesetzliche Hauptuntersuchung. Als Zielplattformen sollen dabei mobile Endgeräte wie Smartphones oder Tablet PCs, aber auch Einplatinencomputer sowie stationäre Rechner und Laptops dienen. Der Algorithmus soll die Lichter dabei auf folgende Eigenschaften hin untersuchen:
  1. generelle Funktionstüchtigkeit
  2. Helligkeitsunterschiede zwischen dem linken und rechten Licht
  3. korrekte Lichtfarbe nach Tabelle (siehe oben)
  4. Blinkfrequenz bei Fahrtrichtungsanzeigern
  Die Ausgabe soll z.B. in Form eines Prüfprotokolls erfolgen. Die Steuerung der Licht-
  funktionen erfolgt über eine Drahtlosverbindung zur Diagnoseschnittstelle, bzw. eines
  daran angebrachten Adapters, des Fahrzeugs.
  Eine Erkennung der Höheneinstellung der Scheinwerfer ist nicht vorgesehen, da bereits
  digitale Geräte existieren, die diese Aufgabe übernehmen.




• Anforderungen

  Für die Erkennung von Fahrzeuglichtfunktionen, wie in der Zielstellung beschrieben, sind vier wesentliche Punkte zu beachten. Zum einen muss das Erfassen der Lichter möglich sein, was eine Kamera als optischen Sensor erfordert. Zum zweiten müssen die zu erkennenden Lichter des Fahrzeugs vom Programm aktiviert werden können, was die Kommunikation mit dem Fahrzeug erfordert. Beide Funktionen müssen auf einer dafür geeigneten Plattform betrieben werden. Entweder als Lösung, die Aufnahme, Kommunikation, Analyse und Anzeige auf einem Gerät vereint oder als Kombination von einzelnen Komponenten wie Kamera, Kommunikation, Verarbeitung und Anzeige auf verschiedenen Geräten, die miteinander kommunizieren. Dazu muss das zu entwickelnde Programm auf verschiedenen Plattformen lauffähig sein.

  Plattform

  [table id=8 /]

  Kamera

  Die Kamera als Sensor für die Fahrzeuglichterkennung muss je nach Einsatzzweck verschiedene Eigenschaften erfüllen. Hauptaugenmerk liegt dabei in der Erkennung der Lichter, der eventuell vorhandenen Helligkeitsunterschiede, der Lichtfarbe und der Blinkfrequenz von  Fahrtrichtungsanzeigern. Dazu ist die manuelle Steuerung der Belichtungsparameter (Belichtungszeit, Blende, Verstärkung) für die Erkennung der Lichter, Helligkeitsunterschiede und Blinkfrequenz sowie die manuelle Steuerung des Weißabgleichs für die Bewertung der Lichtfarbe notwendig.

  Leider bieten Consumer Kameras, wie sie z.B. auch im Smartphones, Webcams usw. zu finden sind, oft nur eine rudimentäre Implementierung dieser Steuermöglichkeiten, da für den alltäglichen Gebrauch die Automatikfunktionen ausreichend sind. Hierfür eignen sich eher Industriekameras mit komplett manuell einstellbaren Aufnahmeparametern.

  Kommunikation

  Für eine vollautomatische Lichterkennung muss eine Kommunikation mit dem Fahrzeug bzw. dessen internem Bus (üblicherweise CAN-Bus) stattfinden. Dies ist nur möglich, wenn die einzelnen Komponenten über einen Computer elektronisch angesteuert werden können. Da bei der Nutzung von mobilen Endgeräten eine direkte Verkabelung mit dem Fahrzeug schwer möglich ist, wird eine kabellose Variante benötigt. Eine günstige Alternative mit gutem Funktionsumfang bietet hierbei das Produkt WLAN-CAN Cube 3.0 der Firma Avisaro AG. Das Gerät besitzt u.a. eine CAN Schnittstelle sowie ein WLAN Modul. Außerdem ermöglicht es die Ausführung von selbst geschriebenen Scripten, was die Einsatzmöglichkeiten stark erweitert. Die Spannungsversorgung erfolgt über einen 12V Zigarettenanzünder Anschluss im Fahrzeug. Damit erfüllt es alle gestellten Anforderungen.

  Software

  Zur Erkennung von Fahrzeuglichtern in einem Videobild werden verschiedene Filter- und Detektionsalgorithmen benötigt. Hierzu eignen sich verschiedene Software-Bibliotheken, die zum Beispiel in der Robotik/Computervision verwendet werden. Bei der Wahl der richtigen Bibliothek sollte vor allem auf die Kompatibilität zu verschiedenen Betriebssystemen beachtet werden. Es können sowohl mobile als auch Desktop Lösungen als Zielplattform dienen. Die auf diesen Plattformen gängigen Betriebssysteme Windows, Linux, Mac OSX, iOS sowie Android sollten demnach alle unterstützt werden. Zudem ist darauf zu achten, dass oft leistungsschwache Hardware eingesetzt wird, daher sollte die Bildverarbeitung z.B. durch Parallelisierung oder Hardwarenutzung hoch optimiert ablaufen. Eine gute Wahl ist hier die Nutzung der Open Source Bibliothek OpenCV.

  Die grafische Benutzeroberfläche muss für touchbasierte Eingabegeräte sowie für herkömmliche Maus- und Tastatureingaben konzipiert werden. Dabei hat sich das Open Source Python Framework kivy als Favorit herausgestellt.
  




• Konzepte und Implementierung

  Fahrzeugschnittstelle

  Zur Steuerung der Fahrzeuglichtfunktionen wird das Avisaro Modul so programmiert, dass es sich automatisch im WLAN Netzwerk einwählt und auf einem TCP Port auf Pakete wartet, deren Inhalt dann direkt auf den CAN-Bus weitergeleitet werden. Die CAN Nachrichten für die Lichter wurden für das Testfahrzeug mittels reverse-engineering herausgefunden. Auf Rechnerseite übernimmt ein Python Modul den Versand der TCP/CAN Botschaften.

  Der Testaufbau sieht wie folgt aus:

  

  Lichterkennung

  Die Lichterkennung basiert auf der Erzeugung eines Differenzbildes, das auf Änderungen der Pixelhelligkeit untersucht wird. Dies geschieht über die Aufnahme eines Referenzbildes, das das Fahrzeug ohne eingeschaltete Lichter enthält. Dieses Referenzbild wird mit einer Aufnahme verglichen, auf der die Lichter eingeschaltet sind. Durch Schwellenwertbildung sowie Finden von Konturen können die Bereiche, in denen sich die Bilder unterscheiden, was im optimalen Fall nur die eingeschalteten Lichter sind, extrahiert und einzeln auf ihre Farbe und Helligkeit analysiert werden. Die Durchführung ist im Flussdiagramm noch einmal grafisch verdeutlicht.

  

  Die detektierten Bereiche, in denen sich die Lichter befinden, können nun auf ihre Helligkeit, Farbe und ggf. Blinfrequenz analysiert werden.

  

  Zur Messung der Blinkfrequenz wird ein Video über 10 Sekunden aufgenommen und die Helligkeit nachträglich mittels FFT analysiert. Durch die nachträgliche Analyse kann dieses Verfahren auch für leistungsschwache Geräte eingesetzt werden, solange die Bildrate während der Aufnahme stabil bleibt.
  

  Grafische Benutzeroberfläche

  Um die Lichtsteuerung und -detektion auf verschiedenen Plattformen für den Nutzer bedienbar zu machen, muss ein entsprechendes GUI bereitgestellt werden, das die Funktionen mit wenigen Klicks verfügbar macht. Da in der Masterarbeit lediglich ein Prototyp und kein verkaufsfertiges Produkt entwickelt werden soll, wird vor allem Wert auf die Grundfunktionalität gelegt und weniger auf Design und Fehlerbehandlung bei Falscheingaben. Die Nutzeroberfläche wurde mit dem Python Modul kivy erstellt und unter einem Linux Desktopbetriebssystem sowie unter Android mit Toucheingaben getestet.

  
  

• Test und Auswertung

  Die Evaluierung der Lichterkennung findet mit dem Testfahrzeug Smart forfour und verschiedenen Geräten sowie Bedingungen statt. Zum Einsatz kommen ein Laptop mit Webcam, ein Raspberry Pi sowie ein Android Smartphone. Beim Testen der verschiedenen Geräte werden alle Lichter an der Fahrzeugfront der Reihe nach auf ihre Funktion überprüft. Zudem wird zur Kontrolle der Blinkfrequenzmessung ein 1 Hz Blinksignal generiert und gemessen. Das Fahrzeug befindet sich hierbei in einer Werkstatthalle, die nur durch einfallendes Licht beleuchtet wird. Ein zusätzlicher Test mit eingeschaltetem Licht soll die Lichterkennung bei unterschiedlichen Beleuchtungssituationen prüfen. Beim Test werden die durchschnittliche Framerate, welche durch die maximale Framerate der Kamera sowie der Bildverarbeitungsgeschwindigkeit bestimmt wird und die Qualität der Detektion ausgewertet.

  Laptop mit Webcam

  Verwendet wurde ein Thinkpad Edge E530 mit einem leistungsfähigen Intel Core i7-3632QM Quadcore Prozessor mit 2.2 GHz bzw. 3.2 GHz im Turbo Modus, 8 GB Arbeitsspeicher und dem Betriebssystem Linux Mint 17 64 Bit. Als Kamera kam eine recht alte Webcam „QuickCam Express“ der Firma Logitech mit der VendorID/ProductID 046d:0928 zum Einsatz. Bei mehrfachen testen wurden alle Lichter ohne Probleme erkannt und auch die Blinkfrequenz korrekt berechnet. Allerdings wurde die Lichtfarbe durch den automatischen Weißabgleich mehrfach falsch detektiert. Die durchschnittliche Framerate lag ohne große Schwankungen bei 30 fps, was der Bildwiederholrate der Kamera entspricht.

  Raspberry Pi mit Webcam

  Beim Test kam ein Raspberry Pi Model B Rev. 2 mit dem Betriebssystem Raspbian wheezy und Linux Kernel 3.18 zum Einsatz. Der Prozessor hat standardmäßig eine Taktfrequenz von 700 MHz, welche mit dem Standardtool raspi-config auf 800 MHz gesetzt wurde. Von den 512 MB Arbeitsspeicher werden 128 MB für die Grafikkarte reserviert. Als Kamera kam wieder die Logitech QickCam Express zum Einsatz. Die Webcam wurde zwar vom System erkannt, bereitete aber mehrfach Probleme. So erschien beim Start der Detektion mehrfach die Fehlermeldung „Broken pipe”, die vom V4L2 Treiber ausgegeben wurde. Dabei war bis zum Neustart des Raspberry Pis keine Bildaufnahme mehr möglich. Des weiteren sank die Framerate von den durchschnittlichen 10 fps mehrfach auf unter 0.5 fps, wobei simultan die V4L2 Fehlermeldung „select timeout” ausgegeben wurde. Oft mündete dieser Fehler wieder in der „Broken pipe” Fehlermeldung, die nur durch Neustart beseitigt werden konnte. Zur Problembehebung wurden verschiedene Netzteile für den Raspberry Pi sowie ein aktiver USB Hub für die Webcam sowie aktuellste Treiber getestet. Leider konnten die Fehler dadurch nicht behoben werden. Die Testreihe konnte aufgrund der genannten Kameraprobleme nur bei einem von 15 Anläufen komplett durchlaufen werden. Die durchschnittliche Framerate lag hierbei bei 10 fps und der Algorithmus selbst hatte keine Probleme alle Lichter zu erkennen, sowie die korrekte Blinkfrequenz zu ermitteln. Allerdings wurde die Lichtfarbe auch hier aufgrund des automatischen Weißabgleichs mehrfach falsch detektiert.

  Android Smartphone mit interner Kamera

  Zum Einsatz kam ein Android Smartphone „Galaxy S4 Mini” von Samsung mit Android 4.4.2 Betriebssystem. Das Gerät besitzt einen Dualcore Snapdragon-S4-Prozessor mit jeweils 1,7 GHz Taktfrequenz und 1,5 GB Arbeitsspeicher. Zur Detektion kommt die eingebaute 8 Megapixel Kamera zum Einsatz. Obwohl die Steuerung der Belichtungszeit für die Kamera bzw. den verwendeten Treiber nicht möglich sein soll, wäre zumindest eine Messung der Framerate während der Bildverarbeitung interessant gewesen. Leider erhält das Detektionsprogramm trotz gesetzter Rechte keinen Zugriff auf die Kamera und stürzt ab. Verschiedene Nutzer scheinen das selbe Problem zu haben, was jedoch nur bei bestimmten Android Versionen und Geräten auftreten soll. Da der Zugriff auf die Kamera nicht möglich war, konnten keine auswertbaren Daten bezüglich Framerate sowie Qualität der Detektion gewonnen werden.

  Verschiedene Lichtsituationen

  Um die Robustheit des Detektionsalgorithmus bei verschiedenen Lichtsituationen zu testen, wurden mit der Kombination „Laptop mit Webcam” jeweils mehrere Testläufe bei ausgeschaltetem sowie eingeschaltetem Hallenlicht durchgeführt. Bei fast allen Durchgängen wurden alle Lichter richtig erkannt. Lediglich die Lichtfarbe schwankte aufgrund des automatischen Weißabgleichs. Bei einigen Testläufen mit eingeschaltetem Licht hat allerdings die Kalibrierung der Webcam versagt. Hier schwankte die Belichtungszeit mehrfach um verschiedene Werte. Dies könnte durch das 50 Hz Flackern der Beleuchtung ausgelöst wurden sein, wodurch das Bild bei sehr kurzen Belichtungszeiten mal heller, mal dunkler ist. Moderne Kameras mit Videofunktion besitzen hier oft interne Algorithmen, die diesen sogenannten „banding” Effekt kompensieren.

  Auswertung

  Wie die Testreihen zeigen, funktioniert der Detektionsalgorithmus sowie die Berechnung der Blinkfrequenz auf verschiedener Hardware und unter verschiedenen Lichtsituationen ohne Probleme. Lediglich die Erkennung der Lichtfarbe ist aufgrund des automatischen Weißabgleichs oft fehlerhaft. Hier muss entweder an einer Lösung gearbeitet werden, die einen manuellen Weißabgleich ermöglicht oder auf das Feature verzichtet
  werden.
  Große Probleme hingegen bereitet die Ansteuerung der Kamera. Nicht nur, dass viele Geräte die Steuerung der Belichtungsparameter nicht unterstützen, auch die Treiberstabilität sowie der Zugriff unter verschiedenen Betriebssystemen bereitet oft Probleme. Hier muss durch Verbesserung der OpenCV Kameraschnittstelle oder Wahl einer besseren, robusteren Schnittstelle, nachgeholfen werden. Alternativ könnte man das Problem auch durch das Finden einer Kamera, die alle Kriterien in Puncto Einstellungen und Treiberstabilität erfüllt, hardwareseitig beheben.