Newsletters

  • Vertrieb kontaktieren

Entwicklung und Implementierung einer Videoverarbeitungs-Anwendung mit Model-Based Design

Von Houman Zarrinkoub, MathWorks

Nach Aussagen der US-Verkehrssicherheitsbehörde verursacht das plötzliche Verlassen der Fahrspur immer wieder schwere Unfälle. Um die Wahrscheinlichkeit solcher Fahrfehler zu verringern, haben Automobilingenieure Spurassistenten entwickelt, die den Fahrer beim Abkommen von der Fahrspur warnen. Sie arbeiten mit kleinen Kameras, die Videoinformationen zum Spurverlauf und zu den Straßenverhältnissen sammeln und an ein spezielles, im Fahrzeug untergebrachtes Gerät übermitteln.

In diesem Artikel stellen wir die Entwicklung eines Spurassistenten mit Hilfe von Model-Based Design mit Simulink und dem Video and Image Processing Blockset vor. Wir zeigen, wie das System auf einem DSP von Texas Instruments implementiert und seine Leistung auf dem Target in Echt-zeit verifiziert wird.

Das Herzstück des Model-Based Design ist ein exaktes Systemmodell, das als ausführbare Spezifikation alle Anforderungen an die Software- und Hardware-Implementierung inklusive des Festkomma- und Timing-Verhaltens enthält. Aus diesem Modell wird sowohl der Programmcode als auch die Testumgebung für die Verifikation und den Praxistest automatisch generiert.

Dieser Ansatz ermöglicht eine leicht verständliche Darstellung des Entwicklungskonzepts, die Simulation des Modells zur Verifikation der Algorithmen, die automatische Erzeugung des Programmcodes für das Target und die Verifikation, dass sich der generierte Code auf der Hardware genau so verhält wie das Modell in der Simulation.

Aufbau des Systemmodells

Mit Simulink, dem Signal Processing Blockset und dem Video and Image Processing Blockset entwickeln wir das Fließkommamodell des Spurassistenten. Die Erkennung der Fahrbahnmarkierungen als Liniensegmente erfolgt durch Maximierung der Hough-Transformation der in einem Videobild gefundenen Kanten.

Zur Einspeisung des Videostroms in die Simulationsumgebung dient der Block ‚From Multimedia File’ aus dem Video and Image Processing Blockset. Die eingehenden Videodaten werden im Subsystem ‚Lane Marker Detection and Tracking’ verarbeitet, das die Ergebnisse des Erkennungsalgorithmus an den Block ‚To Video Display’ zur Anzeige übergibt (Abb. 1).

vip_fig1_w.gif

 

Abb. 1. Modell zur Spurerkennung. Zum Vergrößern auf das Bild klicken.

vip_fig2_w.gif

 

Abb. 2. Fließkommamodell: Subsystem zur Erkennung und Verfolgung der Fahrbahnmarkierungen. Zum Vergrößern auf das Bild klicken.

Spurerkennung und -visualisierung

Abbildung 2 zeigt das Subsystem mit dem Kernbestandteil unseres Simulink-Modells. Die Reihenfolge der Subsysteme im Modell entspricht dem Ablauf der einzelnen Schritte des Algorithmus zur Erkennung und Verfolgung der Fahrbahnmarkierungen.

In einem Vorverarbeitungsschritt wird zunächst das Blickfeld festgelegt und dieser Bildbereich gefiltert, um das Rauschen zu verringern. Der Edge Detection-Block des Video and Image Processing Blockset berechnet dann die im Bild vorhandenen Kanten. Er erstellt ein Binärbild in Form einer Boolschen Matrix, in der Pixelwerte gleich „1“ gefundenen Kanten entsprechen. Für diese Berechnung kann man wahlweise die Sobel-, Prewitt-, Roberts- oder Canny-Methode einsetzen.

Anschließend identifizieren wir Linien im Bild mit dem Houg Transform-Block. Er bildet mit Hilfe der folgenden Gleichung Punkte im Kartesischen Bildraum auf Kurven im Hough-Parameterraum ab:

rho =  x * cos(theta) + y * sin(theta)

Das Ergebnis ist eine Parameterraum-Matrix, deren Zeilen und Spalten den rho- und theta-Werten der Gleichung entsprechen. Die Maximalwerte dieser Matrix kenn-zeichnen mögliche Linien im Eingabebild.

Um die Fahrbahnmarkierungen sicher zu erkennen, arbeitet das Subsystem ‚Lane Marker Detection and Tracking’ mit einer Rückkopplungsschleife. Das Ergebnis der Hough-Transformation wird mit einer Korrektur der Liniensegmente nachbearbeitet, um auch Abschnitte zu berücksichtigen, die außerhalb der Bildbegrenzung liegen. Erst danach werden die Hough-Linien berechnet. Der Hough Lines-Block des Video and Image Processing Blockset findet die Kartesischen Koordinaten der Linienendpunkte durch Berechnung der Schnittpunkte der erkannten Linien anhand der theta- und rho-Werte der Matrix und des Randes des Referenzbildes.

Mit Hilfe der Schnittpunkte zeichnet das Subsystem ein Polygon und rekonstruiert das Bild. Das Polygon, dessen Seiten der erkannten Fahrspur entsprechen, wird nun im Originalvideo eingeblendet. Die Spurerkennung und –verfolgung wird durch Simulation des Modells verifiziert (Abb. 3).

vip_fig3_w.gif

 

Abb. 3. Simulationsergebnisse der Spurerkennung: Das Trapez zeigt den Verlauf der Fahrspur im Videobild an. Zum Vergrößern auf das Bild klicken.

Umwandlung der Fließkomma- in eine Festkommadarstellung

Zur Implementierung des Systems auf einem Festkomma-Prozessor müssen die Datentypen des Algorithmus umgewandelt werden. Bei der herkömmlichen Entwicklung in C ist diese Modifikation des Programmcodes sehr aufwändig. Unter Simulink sind dazu lediglich drei Schritte nötig:
  1. Veränderung der Ausgabedatentypen des Source-Blocks; Simulink gibt Datentypen automatisch weiter und zeigt die Blockparameter an, die verändert werden müssen, damit die Datentypen über das gesamte Modell hinweg konsistent sind.
  2. Festlegung der Festkomma-Attribute der Ausgaben aller Speicher- und Ergebnisblöcke (z.B. Minmax- und Überlauf- Protokollierung) mit Simulink Fixed-Point Werkzeugen.
  3. Überprüfung aller Blöcke, deren Para-meter empfindlich von den Pixelwerten abhängen, um sicherzustellen, dass diese Parameter mit dem Datentyp des Eingangssignals konsistent sind. (Die Interpretation der Pixelwerte ist abhängig vom Datentyp. In der Fließkommadarstellung beträgt z.B. die Maximalintensität eines Pixels 1, bei vorzeichenlosen 8-Bit-Integers dagegen 255.)

Abbildung 4 zeigt das fertige Festkommamodell. Es läuft in der Simulation unter Umständen langsamer als das Fließkommamodell, weil Festkommaoperatoren dynamisch nach Überläufen suchen und Skalierungs- und Sättigungseinstellungen vornehmen. Zur Beschleunigung der Simulation kann man in den Accelerator-Modus wechseln. Der Simulink Accelerator kann die Ausführungsgeschwindigkeit großer Simulink-Modelle wesentlich verbessern, indem allgemeine Simulink-Blöcke, die mit jeglicher Konfiguration lauffähig sind, durch kompilierte modellspezifische Versionen ersetzt werden. Im Accelerator-Modus erreicht ein Festkommamodell die Geschwindigkeit von kompiliertem C-Code.

vip_fig4_w.gif

 

Abb. 4. Simulationsergebnisse der Spurerkennung: Das Trapez zeigt den Verlauf der Fahrspur im Videobild an. Zum Vergrößern auf das Bild klicken.

Implementierung und Verifikation der Anwendung auf TI-Hardware

Mit Real-Time Workshop und Real-Time Workshop Embedded Coder wird der Programmcode automatisch aus dem Modell generiert. Anschließend erfolgt die Implementierung der Anwendung mit dem Embedded Target for TI C6000™ DSP auf einem TI C6400™-Prozessor. Um zu verifizieren, dass die Implementierung den Ausgangsspezifikationen entspricht, führen wir mit Link for Code Composer Studio™ eine Echtzeit-Validierung in Form von Hardware-in-the-Loop-Tests durch und überwachen die Ausführung der Anwendung auf der Hardware mit geeigneten Anzeigefunktionen.

Bevor wir den Entwurf auf einem TI C6416DSK-Evaluierungsboard implementieren können, müssen wir den noch Target-unabhängigen Festkommacode in Target-spezifischen Code umwandeln. Dazu nutzen wir Real-Time Data eXchange (RTDX), ein von TI entwickeltes Echtzeit-Protokoll für den Datentransfer zum und vom Host. Die RTDX-Blöcke ermöglichen es, die gleiche Testumgebung, die zur Validierung des Modells per Simulation verwendet wurde, auch für die Implementierung zu nutzen.

Die Erzeugung des Target-spezifischen Modells erfolgt in drei Schritten:
  1. Ersetzen des Source-Blocks des Target-unabhängigen Modells durch den From RTDX-Block und Einstellen seiner Parameter.
  2. Ersetzen des Video Viewer-Blocks des Target-unabhängigen Modells durch den To RTDX-Block und Einstellen seiner Parameter.
  3. Einrichten der Target-spezifischen Einstellungen im Real-Time Workshop. Dazu wird ein zum gewählten Board passender Block aus der C6000 Target Preference-Bibliothek per Drag-and-Drop in das Modell eingefügt. Abbildung 5 zeigt das Target-spezifisch konfigurierte Modell.
vip_fig5_w.gif

 

Abb. 5. Der TI C6416 DSK-Block stellt alle Real-Time Workshop-Parameter automatisch ein und nutzt dazu die Konfiguration des TI-Boards und des lokal installierten Code Composer Studio. Zum Vergrößern auf das Bild klicken.

Um die Erzeugung der Anwendung und die Verifikation ihres Echtzeitverhaltens zu automatisieren, erzeugen wir ein Skript für Link for Code Composer Studio, das folgende Aufgaben ausführt:

  1. Aufrufen der IDE des Link for Code Composer Studio und automatische Erzeugung des Link for Code Composer Studio-Projekts.
  2. Kompilieren und Verlinken des aus dem Modell erzeugten Programmcodes.
  3. Übertragen des Codes auf das Target.
  4. Ausführung des Codes: Senden des Videosignals an das Target-spezifische Modell aus der gleichen, in der Simulation verwendeten Videodatei und Abrufen der vom DSP verarbeiteten Videodaten.
  5. Grafische Darstellung der Ergebnisse in einem MATLAB-Diagrammfenster.

In Abbildung 6 ist das verwendete Skript dargestellt. Link for Code Composer Studio verfügt über eine Reihe aus MATLAB heraus aufrufbarer Funktionen zur Parametrie-rung und Automatisierung von Testskripts, mit denen sich die gesamte Verifikation von Embedded Software automatisieren lässt.

vip_fig6_w.gif

 

Abb. 6. IDE-Skript für Link for Code Composer Studio. Zum Vergrößern auf das Bild klicken.

Abbildung 7 zeigt die Ergebnisse des auf dem Target-DSP laufenden, automatisch generierten Codes. Man sieht, dass die auf der Targethardware laufende Anwendung die Fahrspur korrekt erkennt. Wir verifizieren damit, dass die Anwendung die Anforderungen des ursprünglichen Modells erfüllt.

vip_fig7_w.gif

 

Abb. 7. Die Ausführung des automatisch erzeugten Codes auf dem Target-DSP verifiziert, dass die Anwendung die Fahrbahn korrekt erkennt. Zum Vergrößern auf das Bild klicken.

Der Test unserer Anwendung auf dem Target hätte auch zeigen können, dass der Algorithmus die Anforderungen der Echtzeithardware nicht erfüllt. Da beim Model-Based Design die Simulation und die Codegenerierung auf demselben Modell basieren, könnten wir den Entwurf schnell durch weitere Iterationen optimieren. Link for Code Composer Studio verfügt z.B. über Profiling-Funktionen, um die rechenintensivsten Teile des Algorithmus zu identifizieren. Auf der Grundlage dieser Ana-lyse könnten wir dann Modellparameter verändern, einen effizienteren Algorithmus verwenden oder auch allgemeine Simulink-Blöcke im Modell gegen optimierte Blöcke aus dem Embedded Target for TI C6000™ austauschen. Auf diese Weise können wir die Anwendung weiter verbessern und die optimale Leistung auf dem Target erzielen.

Veröffentlicht 2006

Receive the latest MATLAB and Simulink technical articles.

Related Resources

Latest Blogs