Um einem Computer das sichere Fahren beizubringen braucht man zunächst einmal eines: Eine beliebig gigantische Menge an aus Sensorik gewonnenen, Umgebungsdaten die potenziell dazu in der Lage sind, jede erdenkliche Verkehrssituation in beliebig vielen Variationen darzustellen. Um diese initialen Daten zu generieren bieten sich mir zwei Möglichkeiten: 1. man fährt mit einem mit Technik und Sensorik vollgestopften Auto sehr lange durch die Gegend in der Hoffnung die ein oder andere Ausnahmesituation einfangen zu können… oder 2. man baut sich eine Simulation, die möglichst realistisch ist, in der man alle Standard- und Spezial- Situationen systematisch und gezielt durchspielen kann und die erheblich weniger Aufwand/Kosten bei selben Nutzen darstellt.
Die nächste Frage, die sich stellt, ist: wie sollen die Daten erfasst werden? Welche Sensorik ist zu verwenden, die zum einen technische Machbarkeit gewährleistet, zum anderen billig massenhaft einbaubar ist? Die Lösung mit dem besten Verhältnis zwischen Kompaktheit, Preis, gelieferter aussagekräftiger Datenmenge und zur Genüge erforschten Technik ist offensichtlich die Kamera, die dem teuren, klobigen Laider, dem nur Metall detektierenden Radar und den unscharfen Ultraschallsensoren gegenübersteht. Das Problem, das eine Kamera bietet, ist, dass die Umgebungsdaten durch die verrauschte Projektion auf die Bildebene auf komplizierte Weise kodiert sind. Reflexionen und Spiegelungen, unterschiedliche Helligkeiten bei schnellen Helligkeitswechseln, Tiefenschärfe, fresnelsche Linsen-Effekte und Farbabberationen kommen erschwerend hinzu. Dass es aber dennoch gelingen kann sicheres autonomes Fahren unter verschiedensten Bedingungen allein durch Kameras zu garantieren, kann man am Menschen selbst erkennen, den man approximativ mit etwas Vorstellungskraft und Optimismus als Turing-Maschine ansehen kann. Die erste Forderung ist also, dass mit dem Fahrzeug ein zuverlässiges autonomes Fahren allein mit Kameras möglich ist. Jedoch kann zur allgemeinen Performancesteigerung auch andere Sensorik verwendet werden. Es geht also primär um die Auswertung und die Umsetzung von Kameradaten. Wichtig ist also eine präzise und echtzeitfähige Produktion von Kameratrainingsdaten. Allzu präzise Daten bezüglich Fahrzeugdynamik und Effekten im Grenzbereich sind guten Gewissens für die initiale Autonomie des Fahrzeuges auf öffentlichen Straßen zu vernachlässigen. Daher verwende ich zur Generierung von Umgebungsdaten nichts konventionelles wie Carmaker, sondern die Realtime-Physical-Based-Render Engine von Blender in Kombination mit der Physikengine Bullet. So kann in Echtzeit bestmöglicher Fotorealismus garantiert werden.
import numpy as np import cv2 from PIL import ImageGrab import time def process_img(ori_image): proc_image = cv2.cvtColor(ori_image, cv2.COLOR_BGR2GRAY) cv2.imshow('window_gray', proc_image) # comment ggf proc_image = cv2.Canny(proc_image,200,300) return proc_image l_time=time.time() while(True): bildschirm = np.array(ImageGrab.grab(bbox=(125,55,800*1.45,640*1.0))) bildschirm = process_img(bildschirm) print('framerate zum Auswerten: {} sekunden'.format(time.time()-l_time)) l_time=time.time() cv2.imshow('window edge_dect', bildschirm) if cv2.waitKey(1) & 0xFF == ord('q'): cv2.destroyAllWindows() break
Als nächstes muss sichergestellt werden, dass unter realen Hardware Anforderungen unabhängig von dem Echtzeit-Generator selbst das Bildmaterial in die Pipeline eingespeist wird. Dies wird durch stumpfes Aufnehmen des Bildschirms beim Renderfenster bewirkt. Links sieht man den grundlegenden Screen-Recording Code. Der aufgenommene Screen wird beispielhaft durch einen RGB-To-Gray-Converter gejagt und durch eine konventionelle Edge-Detection. Dies wird später u.a. durch eine komplexe neuronale Pipeline ersetzt.
Im unten angezeigten Video wird Echzeitsimulation, Screen-Recording und Echtzeit-Verarbeitung simultan in Echtzeit vorgeführt. Benutzt wurde ein normaler Office-PC mit einer RX-460-Grafikkarte. Durch die gleichzeitige Bildschirmaufnahme entstehen merkliche Ruckler, schließlich werden auf einem schwachen System gleich vier aufwändige Anwendungen ausgeführt. Ohne aufzunehmen arbeitet die Simulation auf der Grafikkarte stabil bei 40 FPS und die Auswertung auf dem Prozessor bei 5 fps. Grafikkartenbeschleunigung vervielfacht diesen Wert.
Die Simulation benutzt für annehmbaren Realismus ein Suspensionmodell, das unterschiedliche Stifness und Drag Parameter berücksichtigt. In der unten gezeigten Aufzeichnung ist das PBR-Rendering noch deaktiviert, da ich hier noch einige Dinge justieren muss. Verschiedene Szenerien werden im übernächsten Schritt bei einem stehendem, tainigsfähigem System unter Orientierung an Googles Karten/Szenerie-Material erstellt/generiert und mit genanntem PBR-Realismus kalkuliert.
Anschließend muss gewährleistet sein, dass die Ausgabe der Pipeline Einfluss auf die Physik-Engine nehmen kann um das Auto virtuell zu steuern. Lenkwinkelgeschwindigkeit und Drehmoment wird hinreichend durch Generierung von Tastatureingaben nach stetigem Verlauf eingestellt. Die grundsätzliche Umgebung und eine noch dumme Verarbeitung sind nun konstruiert. In einem folgenden Artikel geht es dann um die Konstruktion der Pipeline.