Achtung:

Sie haben Javascript deaktiviert!
Sie haben versucht eine Funktion zu nutzen, die nur mit Javascript möglich ist. Um sämtliche Funktionalitäten unserer Internetseite zu nutzen, aktivieren Sie bitte Javascript in Ihrem Browser.

Bildinformationen anzeigen

Einsatz von Deferred Rendering Pipelines in HiL-Test von kamerabasierten ADAS

Die Sicherheits- und Komfortansprüche von Autofahrern steigen immer weiter an. Dies stellt die Automobilindustrie vor immer neue Herausforderungen. Heutzutage tragen insbesondere Fahrerassistenzsysteme zur Erhöhung der Verkehrssicherheit und zur Entlastung des Fahrers bei der Durchführung seiner alltäglichen Routineaufgabe bei [dSP14, S. 26]. Es finden zunehmend mehr Innovationen und Entwicklungen in diesem Bereich statt. Die Sensorik dieser Systeme beschränkt sich nicht nur auf Radar-, Laser- oder Ultraschallsysteme, sondern wurde inzwischen auch auf Kameras in Verbindung mit Echtzeitbildverarbeitung ausgedehnt.

Der Vorteil von Kameras liegt in den vielseitigen Einsatzmöglichkeiten bezüglich der Erkennungsaufgaben, wie zum Beispiel der Erkennung von Fahrspuren, Fußgängern und Verkehrszeichen. Zur Absicherung der korrekten Funktionalität müssen die Fahrerassistenzsysteme getestet werden. Reale Testfahrten bringen Nachteile mit sich. Um diese zu vermeiden, wird auf Hardware-in-the-Loop-Testsysteme (kurz: HIL-Testsysteme), bei denen keine Fahrt mit einem realen Fahrzeug durchgeführt werden muss, zurückgegriffen.

Um aussagekräftige Testergebnisse zu erhalten, muss das Rendering möglichst realistisch sein. Aus diesem Grund müssen insbesondere die Beleuchtungsgegebenheiten angemessen umgesetzt werden. Dies ist nur dann der Fall, wenn komplexe physikalische Abläufe der Lichtinteraktion im Freien berücksichtigt werden. Standard-Beleuchtungsmodelle, wie zum Beispiel das Phong-Beleuchtungsmodell, neigen zu extremen Schattierungen, die bei kamerabasierten Tests zu fehlerhaften Ergebnissen führen können.

Um diese ein physikalisch korrektes Beleuchtungsmodell nutzen zu können, greifen wir auf Deferred Rendering zurückgegriffen. Deferred Rendering eine effiziente Methode, um viele Lichtquellen zu handhaben. Die Umsetzung des Beleuchtungsmodells unter Verwendung des Deferred Renderings legt den Grundstein für weitere Ausarbeitungen von realistischen 3D-Visualisierungen für die ADAS-Tests. Hierzu gehört die korrekte Umsetzung von Transparenzen, Schatten, Wetterbedingungen etc..

Was ist Deferred Rendering?

Deferred Renderingstellt eine Alternative zum traditionellen Forward Rendering dar. Beim Deferred Rendering muss durch die Trennung von Geometrieverarbeitung und Beleuchtungsberechnung während des Zeichnens der Szenengeometrie der Beleuchtung keine Aufmerksamkeit zugewendet werden [Har04, S. 2]. In Abbildung 2 wird der Ablauf des Deferred Shadings skizziert. Die Geometrieverarbeitung findet in der Geometriephase und die Beleuchtungsberechnung in einer separaten Beleuchtungsphase statt. In der Geometriephase werden alle für die Beleuchtungsberechnung notwendigen Daten der 3D-Szene im Geometrie Buffer (kurz: G-Buffer) gesammelt [BS13, S. 443] [Eng13, S. 101] [Ki11, S. 33]. Zu diesen Informationen gehören insbesondere die Position, die Normalen und die diffusen Farben [HH04, S. 7] [Ki11, S.33f.]. Diese Daten in Form von Texturen gespeichert. Die Beleuchtungsberechnung wird abgespalten und mit Hilfe des G-Buffers verzögert (engl. deferred) durchgeführt. Die Geometriedaten werden aus dem G-Buffer gelesen und die Shading-Operationen werden als Post-Prozess ausgeführt [Ki11, S. 33]. Da die Post-Prozess-Berechnungen nur auf den sichtbaren Teil der Szene begrenzt werden, werden keine unnötigen Berechnungen für verdeckte und nicht sichtbare Objekte durchgeführt [KRP11, S. 55] [MB05, S. 167]. 

Die Worst-Case-Laufzeit beträgt beim Deferred Shading O(n). Das Deferred Shading arbeitet für viele Lichtquellen und komplexe Szenen somit weitaus effizienter als das Forward Shading, das im Worst-Case eine Laufzeit von O(n2) aufweist [BS13, S. 443] [Har04, S. 6] [HH04, S. 4].

Abbildung 2: Ablauf des Deferred Shadings inklusive Beispiel für den G-Buffer und dem daraus entstehenden finalen Bild
Was ist ein HIL-Fahrsimulator?

Bevor ein Fahrerassistenzsystem serienmäßig in Fahrzeugen verbaut wird, muss es getestet werden. Nur so kann eine korrekte Funktionalität sichergestellt werden.Tests in Form von Testfahrten mit realen Fahrzeugen, in denen das Fahrerassistenzsystem verbaut ist, sind aufwendig, kostenintensiv, abhängig von Witterung und Fahrzeugtypen und nur schwer reproduzierbar [Sch10, S. 5]. Für eine solche reale Testfahrt werden Hindernisse, Straßen, weitere Fahrzeuge und bestimmte Witterungsbedingungen benötigt, um eine reale Fahrsituation nachzustellen, die von den Sensoren aufgenommen werden kann [Sch10, S. 5f.]. "Darüber hinaus ist der Test solcher Systeme im öffentlichen Verkehrsraum mit nicht unerheblichen Gefahren verbunden, da eine Fehlfunktion eines Assistenzsystems zu Situationen führen kann,die der menschliche Fahrer nicht mehr beherrschen kann" [Sch10, S. 5]. Dies gilt auch für geübte Testfahrer [Sch10, S. 5]. Um diese Nachteile zu umgehen, wird auf angemessene Testsysteme zurückgegriffen (vgl. Anhang A.1, Frage 7). Ein solches Testsystem greift in den meisten Fällen auf die HIL-Simulation zurück. HIL ist die Abkürzung für Hardware-in-the-Loop und bedeutet, dass reale Hardwarekomponenten in eine simulierte Umgebung eingebunden werden [Sch10, S. 12] [Sch10, S. 75f.]. Abbildung 3 zeigt die Übersicht einer HIL-Simulationsumgebung. Die reale Hardwarekomponente (auch Echtteil genannt), die an die Simulator-Hardware (kurz: Simulator) angeschlossen wird, ist durch den roten Kasten unten rechts dargestellt und kann zum Beispiel ein Fahrerassistenzsystem sein. Der Simulator wird durch die gestrichelte Linie angedeutet. Er enthält Informationen über die Simulation. Unter anderem gehören dazu Informationen über Verkehrsszenarios, die Fahrzeugdynamik und die Sensormodelle (alle durch grüne Rechtecke dargestellt). Die letzte Komponente, die als blauer Kasten dargestellt wird, besteht aus einem oder mehreren Host-PCs, die zur Hardware-Steuerung und zur Visualisierung dienen.

Abbildung 3: Struktur der Simulationsumgebung (angelehnt an [Sch10, S. 9])
Was sind kamerabasierte ADAS?

Kamerasysteme sind Sensoren, die für die Umsetzung der Erkennensaufgabe genutztwerden [Nen14, S. 14]. Beispiele für kamerabasierte Fahrerassistenzsysteme sind Fahrspur-, Fahrzeug-, Fußgänger- und Verkehrszeichenerkennung [Nen14, S. 14]. Abbildung 4 zeigt die Vorgehensweise eines kamerabasierten ADAS. Zunächst wird mit Hilfe der Kamera ein Bild aufgenommen. Nach der Aufnahme des Bildes ist eine Echtzeitbildverarbeitung notwendig, mit der Objekte erkannt und getrackt werden können. Die Trackingdaten werden anschließend von an ein Regelalgorithmus weitergeleitet, der diese auswertet und ggf. eine Reaktion einleitet (z.B. Notbremsung) indem Steuersignale an angeschlossene Aktuatoren (z.B. Bremse) gesendet werden [Mey12, S. 335]. 

Eine Erschwerung der Erkennungsaufgabe entsteht durch die Lichtbedingungen. Je nach Tageszeit und Wetterbedingung herrschen unterschiedliche Lichtverhältnisse. Es kann zum Beispiel zu starkem Schatten oder veränderter spektraler Strahlung des Sonnenlichts kommen. Auf diese muss bei der Bildverarbeitung reagiert werden [Nen14, S. 31]. Es muss sichergestellt werden, dass solche Veränderungen nicht zu einer Fehlinterpretation führen, bei der zum Beispiel weitere Objekte identifiziert werden.

Abbildung 4: Verarbeitungskette kamerabasierter Fahrerassistenzsysteme
Was sind kamerabasierte ADAS-Tests mit HIL-Simulatore?

Bei kamerabasierten ADAS-Tests mit HIL-Simulatoren ist das angeschlossene Echtteil das kamberabasierte Fahrerassistenzsystem. Abbildung 6 zeigt den schematischen Aufbau einer HIL-Simulation zum Testen von kamerabasierten Fahrerassistenzsystemen. Es besteht aus einer echtzeitfähigenSimulator-Hardware (kurz: Simulator; grün) mit angeschlossenem Steuergerät inklusive Kamerasensorik (rot) und einem oder mehreren Host-PCs für die Hardwaresteuerung und das Rendering bzw. die 3D-Visualisierung (blau). Während des Testdurchlaufs wird mit Hilfe eines Host-PCs eine Testszene dargestellt, die vom Simulator mit Hilfe der Kamera aufgenommen und anschließend vom Steuergerät verarbeitet wird. Basierend auf den aufgenommenen Daten berechnet der Simulator Fahrverhalten und Fahrmanöver in Echtzeit, die wiederum über die 3D-Visualisierung ausgegeben werden.

Es ist wichtig, dass die Visualisierung in Echtzeit und mit möglichst geringer Latenz umgesetzt wird, damit die Informationen, die über die Kamera aufgenommen werden, zeitlich exakt mit den anderen Informationen, welche dem System zugeliefert werden,korrelieren [dSP14, S. 48] [NFHS12, S. 14]. Das von der Kamera aufgenommene Bild wird von der IPU verarbeitet und sendet die Trackingdaten der erkannten Objekte wiederum an den Simulator oder an eine ECU, die diese Daten verarbeiten.Falls vorhanden, wird die ECU an den Simulator angeschlossen. Hierdurch wird der Regelkreis geschlossen.Die Visualisierung ist somit ein Teil der Simulation. Folglich bestimmt die Qualität des Renderings die Aussagen über die korrekte Funktionalität des Systems. Über die Visualisierung werden unterschiedliche Umgebungsbedingungen, die in einer echten Fahrsituation gegebenenfalls zu Störfaktoren werden, simuliert.

Schematischer Aufbau eines HIL-Simulators zum Testen von kamerabasierten Fahrerassistenzsystemen
Beispiel: Bremsassistenzsystem

Ein Beispiel für ein Fahrerassistenzsystem, das Kameradaten verwendet, ist das Bremsassistenzsystem mit Fußgängererkennung. "Zahlreiche Untersuchungen haben ergeben, dass Normalfahrer in Schrecksituationen nur zögerlich bremsen, also die volle Betätigung der Bremse und damit ggf. die erforderliche Bremswirkung erst zeitversetzt einsetzt" [Geb10, S. 94]. Ein Bremsassistenzsystem mit integrierter Fußgängererkennung soll eine solche Verzögerung vorbeugen. Es soll den Fahrer zum einen beim Erkennen von Notsituationen unterstützen und so die Reaktionszeit verkürzen und zum anderen die Stärke der Bremsung in Notsituationen anpassen.

Publikationen

[HDD16a]Heppner, S.; Dransfeld, M.; Domik G.: Adding Atmospheric Scattering and Transparency to a Deferred Rendering Pipeline for Camera Based ADAS Tests. In: 14. Workshop Automotive Software Engineering (ASE) - INFORMATIK 2016. Lecture Notes in Informatics (LNI), Volume P-259, pp. 1591 - 1604, GI Bonn 2016.
[HDD16b]Heppner, S.; Dransfeld, M.; Domik G.: A Deferred Rendering Pipeline Including a Global Illumination Model for Atmospheric Scattering and Transparency. At: 21st International Symposium on Vision, Modeling and Visualization (VMV 2016), Bayreuth 2016.

 

Bachelor- und Masterarbeiten 

Literatur

[BS13]Boreskov, Alexey; Shikin, Evgeniy: Computer Graphics – From Pixels to Programmable Graphics Hardware. CRC Press, 2013
[dSP14]dSPACE GmbH (Hrsg.). MotionDesk – Product Information. 2014
[Eng13]Engel, Wolfgang: GPU Pro 4 – Advanced Rendering Techniques. CRC Press, Boca Raton, 2013
[Har04]

Hargreaves, Shawn: Deferred Shading. In: Game Developers Conference. San Francisco, 2004
[HH04]Hargreaves, Shawn; Harris, Mark: Deferred Shading. In: NVIDIA Developer Conference – 6800 Leagues Unter the Sea. London, 2004
[Geb10]Gebhardt, Norbert: Fluidtechnik in Kraftfahrzeugen. Springer, Berlin & Heidelberg, 2010
[Ki11]Ki, Hyunwoo: Multi-Resolution Deferred Shading. In: Lake, Adam (Hrsg.): Game Programming Gems 8. Cengage Learning, Boston, 2011
[KRP11]Knight, Balor; Ritchie, Matthew; Parrish, George: Screen-Space Classification for Efficient Deferred Shading. In: Lengyel, Eric (Hrsg.): Game Engine Gems 2. CRC Press, Boca Raton, 2011
[MB05]McReynolds, Tom; Blythe, David: Advanced Graphics Programming Using OpenGL. Morgan Kaufmann, San Francisco, 2005
[Mey12]Meyer, Gereon: Advanced Microsystems for Automotive Applications 2012 – Smart Systems for Safe, Sustainable and Networked Vehicles. Springer, Berlin & Heidelberg, 2012
[Nen14]Nentwig, Mirko: Untersuchungen zur Anwendung von computergenerierten Kamerabildern für die Entwicklung und den Test von Fahrerassistenzsystemen, Friedrich-Alexander-Universität Erlangen-Nürnberg, Dissertation, 2014
[NFHS12]Nischwitz, Alfred; Fischer, Max; Haberäcker, Peter; Socher, Gudrun: Computergrafik und Bildverarbeitung. Band 1: Computergrafik. 3., neu bearbeitete Auflage. Vieweg+Teubner, Wiesbaden, 2012
[Sch10]Schmidt, Christian: Hardware-in-the-Loop gestützte Entwicklungsplattform für Fahrerassistenzsysteme – Analyse und Generierung kritischer Verkehrsszenarien. Kassel University Press, Kassel, 2010
Sie interessieren sich für:

Die Universität der Informationsgesellschaft