Objekterkennung mit Kinect Tiefenkamera mit Matlab/Simulinkmit und EV3

Autor: Lars Naujocks

Betreuer: Prof. Dr.-Ing. Ulrich Schneider

→ zurück zum Hauptartikel: Signalverarbeitende Systeme SoSe2017

Aufgabe

Die Aufgabe des Projektes für die Vorlesung „Signalverarbeitende Systeme“ besteht darin, ein LEGO Mindstorm Auto (EV3 Brick) mittels eines Sensors zu einer Notbremsung zu bringen, sobald ein Objekt (in diesem Fall ein Kopierpapierkarton) weniger oder gleich 5 cm entfernt ist. Der Sensor ist in diesem Falle eine Kinect Sensorleiste in der Version V2. Die entsprechende Software/Anwendung ist in Matlab und/oder Simulink zu implementieren. Ferner ist ein Video zu erstellen, das die Funktionalität zeigt. Da die Kinect erst ab 0.5 m Tiefenbilder liefert (vgl. Tabelle 1), wurde mit Prof. Schneider vereinbart, einen anderen beliebigen Wert zu nehmen. Für diesen Aufbau wird ein Wert von 0.7 m verwendet.

Einleitung

Abbildung 1: Kinect Version V2

Die Sensorleiste Kinect (abgeleitet vom englischen kinetic connect, deutsch Kinetische Verbindung) der Firma Microsoft wurde ursprünglich für die Spielekonsolen der Xbox-Reihe entwickelt. Sie soll dazu dienen, Videospiele nur durch Körperbewegungen und Sprache zu steuern. Microsoft bietet die Kinect in zwei Versionen an, Kinect V1 (Xbox360 und PC) und Kinect V2 (Xbox One und PC). Die Version V2 besitzt ein 3D-Mikrofon, eine RGB-Kamera, sowie einen Tiefensensor, der nach dem Time-of-Flight Prinzip arbeitet (s. weiter unten). Die Kombination von RGB-Kamera und Tiefensensor wird auch als RGB-D Kamera bezeichnet. Microsoft hat die Entwicklung vom Kinectspielen nahezu eingestellt, dennoch erfreut sich die Kinect in der Informatik und den Ingenieurswissenschaften großer Beliebtheit, da sie einen günstigen Einstieg in die Disziplinen Digitale Bildverarbeitung, Objekterkennung und Robotik bietet. Außerdem existieren mit z.B. OpenCV, OpenNi und Add-Ons für Matlab diverse Softwarepakete, die die Entwicklung eigener Programme unterstützen .

Technische Details zum Kinect System

Der folgende Abschnitt zeigt kurz die technischen Details der Kinect.

Technische Daten

Die u.a. Tabelle zeigt einen Auszug der technischen Daten der Kinect.

Tabelle 1: Technische Daten der Kinect(Auszug)

Auflösung Farbkamera	1920x1080
Bildrate Farbkamera	30 fps
Auflösung Tiefenkamera	512x424
Bildrate Tiefenkamera	30 fps
Tiefensensor	ToF-Sensor
Sichtfeld (FoV) horizontal	70°
Sichtfeld (FoV) vertikal	60°
Unterstütztes Betriebssystem	Ab Windows 8
Minimale Distanz des ToF Sensors	~0.5 m
Maximale Distanz des ToF Sensors	~4.5 m
USB Standard	3.0

Koordinatensystem der Kinect

Abbildung 2: Kinect Koordinatensystem

Wie bereits erwähnt verfügt die Kinect über einen RGB Sensor und einen IR-Tiefensensor nach dem ToF-Prinzip. Der Kameraraum bezieht sich auf das 3D Koordinatensystem, das von der Kinect benutzt wird. Das Koordinatensystem ist wie folgt definiert :

• Ursprung (x=0, y=0, z=0) liegt in der Mitte des IR-Sensors
• rechtshändiges Koordinatensystem
• X wird größer zur linken Seite des Sensors
• Y wird nach oben größer (abhängig von der Neigung der Kinect)
• Z wird in die Richtung größer, in die der Sensor zeigt

Die RGB Kamera ist zum Tiefensensor etwas versetzt, so dass beide eine leicht unterschiedliche "Weltsicht" haben. Möchte man eine kombinierte Farb- und Tiefeninformation haben, ist dieser Unterschied anzupassen, die sogenannte Registration. Dies wird automatisch von der Software (SDK,point cloud library) erledigt, so dass man sich nicht weiter darum kümmern muss.

ToF Sensor

Der ToF Sensor ist das Herzstück der Tiefenmessung. Funktionsweise und technische Daten werden im Folgenden erläutert.

Funktionsweise des ToF Sensors

Die Kinect V2 enthält eine Time-of-Flight (ToF) Kamera, die die Tiefe bzw. Entfernung bestimmt, indem die Zeit gemessen wird von der Lichtemission der IR-Emitter bis zum Objekt und zurück zum IR-Sensor. Hierzu wird konstant IR-Licht mit modulierten Wellen emittiert und die Phasenverschiebung des reflektierten Lichts am IR-Sensor detektiert, siehe auch folgende Abbildung:

Abbildung 3: Prinzip ToF Sensor

Die Berechnung der Distanz erfolgt dann wie folgt :

Bekannte Parameter

c: Lichtgeschwindigkeit (3*10^8 m/s)

f: Frequenz des emittierten Lichts

Gemessen:

$\Delta\varphi$: Phasenverschiebung

Gesucht:

d: Distanz

Es gilt:

$c=\frac{d}{t}$

Daraus folgt (Hin- und Rückweg!)

$\Delta t= 2\cdot \frac{d}{c}$

$\Delta\varphi=2\cdot\pi\cdot f\cdot \Delta t = 2\cdot \pi\cdot f \cdot 2 \frac{d}{c}$

$d=\frac{c \cdot \Delta \varphi}{4 \cdot \pi \cdot f}$

Ein typisches Problem von ToF Sensoren ist der sogenannte "Phase Wrap-Around"-Fehler. Bei einer Phasenverschiebung gilt für die Periode

$k \cdot 2 \cdot\pi$

für jedes beliebige ganzzahlige k. Das bedeutet, dass wenn eine Phase von

$2\cdot \pi$ 

8 m entspricht, dann werden zwei Punkten 0,2 m und 8,2 m die gleichen Messwerte zugeordnet . Die Kinect arbeitet deshalb zur Umgehung dieses Problems bei ihrem ToF-Sensor mit drei Emittern (es gibt anscheinend auch eine Version mit 2 Emittern) mit verschiedenen Frequenzen, um Mehrdeutigkeiten in der Distanzmessung zu reduzieren (niedrigere Frequenzen) und um Unsicherheiten in der Distanzmessung zu reduzieren (höhere Frequenzen) . Die folgende Abbildung verdeutlicht das Vorgehen. Bei einer niedrigen Frequenz wird nur ein Objekt detektiert mit einer relativ hohen Unsicherheit. Bei höheren Frequenzen ist die Unsicherheit kleiner, aber dafür gibt es Mehrdeutigkeiten. Die Kombination von allen erlaubt eine sehr genaue und eindeutige Messung.

Abbildung 4: Umgehung des Phase-Wraparound-Fehlers im Kinect ToF Sensor

Genauigkeit und Präzision des ToF Sensors

Um die Genauigkeit der Messungen selbst einschätzen zu können, wurde ein kleiner Messplatz aufgebaut. Auf einer Länge von 6 m wurde Kreppband befestigt und alle 10 cm eine Markierung aufgetragen. Die Kinect wurde am Nullpunkt befestigt und anschließend Tiefenbilder für verschiedene Entfernungen eines Kartons aufgenommen. Die Bilder wurden in Matlab gespeichert, damit sie später nachprozessiert werden konnten. Da die Präzision, immer den selben Punkt (z.B. Mittelpunkt des Kartons) zu messen, nicht gegeben ist, wurde ein anderer Ansatz zur Bestimmung verwendet: Von jedem Tiefenbild wurde ein Rechteck innerhalb des Kartons gewählt. Diese Koordinaten wurden ausgewertet. Alle Punkte außerhalb des Rechteckes wurden zu null gesetzt. Mittels der mean Funktion von Matlab wurde der Mittelwert der z-Werte (Entfernung) gebildet, der dann als gemessene Entfernung dient.

Der Matlab Code dafür, sieht beispielhaft folgendermaßen aus:

depth = aktuellesTiefenbild;

% Alles außer Kartonkoordinaten

% auf null setzen

% Beispiel: Die ersten zehn Zeilen null

y0 = 1;

y1 = 10;

x0 = 1;

x1 = 512;

for i=y0:y1

for j=x0:x1

depth(i,j) = 0;

end

end

pos = nonzeros(depth);

averdist = mean(pos);

Die nachprozessierten Daten werden gegen die tatsächliche Entfernung aufgetragen. Die folgende Abbildung zeigt das Ergebnis. Die Messungen beginnen bei 0.7 m und enden bei 6 m. Es ist eine sehr gute Linearität der Kennlinie mit hinreichender Genauigkeit zu erkennen, so dass eine Linearisierung oder Kalibrierung für diesen Anwendungsfall nicht nötig ist.

Abbildung 5: Gemessene Werte vs Ideal Werte

Die absoluten und relativen Fehler für die Messungen sind in der folgenden Tabelle einzusehen.

Tabelle 2: Absolute und relative Fehler der Kinectmessungen

Entfernung [m]	Absoluter Fehler [mm]	Relativer Fehler [%]
0.7	15.5905	2.2272
0.8	13.7665	1.7208
0.9	9.8011	1.089
1.0	14.9199	1.492
1.1	21.2209	1.9292
1.2	16.2427	1.3536
1.3	15.2618	1.174
1.5	17.789	1.1859
1.7	29.8047	1.7532
2.0	29.0092	1.4505
2.5	27.9668	1.1187
2.7	32.5772	1.2066
3.0	24.3166	0.81055
3.5	36.3986	1.04
4.0	34.1725	0.85431
4.5	0.053763	0.0011947
5.0	58.4529	1.1691
5.5	84.0955	1.529
6.0	94.3592	1.5727

Kritisch anzumerken ist, dass die Messungen schnell durchgeführt wurden und die Objekte (Kinect - Karton) nicht zueinander ausgerichtet werden konnten. Daher ist die Genauigkeit der Kinect wesentlich höher einzuordnen. Studien zeigen, dass präzise Messungen (alt: Wiederholgenauigkeit) erst nach einer halben Stunde Aufwärmzeit erreicht werden. Nach der halben Stunde liegen bei wiederholten Messungen konstante Werte innerhalb des Variationsintervalls von ± 1 mm vor (s. Abbildung 6).

Abbildung 6: Präzision des ToF Sensors in Abhängigkeit von der Aufwärmzeit

Tiefenauflösung des ToF Sensors

Mit der Auflösung ist in diesem Fall nicht die Anzahl der Pixel des Sensors gemeint, sondern die minimal detektierbare Differenz des Sensors zwischen zwei (oder mehr) Punkten in der Tiefenmessung. Je kleiner die detektierbare Differenz desto höher ist die Auflösung. Hierfür wurden Versuche durchgeführt: Zur Berechnung der Tiefenauflösung wurde eine planare Oberfläche in zwei Winkeln (45 ° und 60 °) zur Kinect ausgerichtet und bei verschiedenen Abständen gemessen. Die Ergebnisse sind in der Abbildung zu sehen. Die Werte zwischen 0 und 0,5 m wurden zu null gesetzt, da dort keine Messung möglich ist. Für einen Winkel von 45 ° ergibt sich eine durchschnittliche Auflösung von 1 mm bei einer Distanz von 1 m bis zu 4 mm bei einer Distanz von 4 m. Für einen Winkel von 60 ° fallen die Werte etwas schlechter aus (ca. 1,3 mm bei 1 m und 6 mm bei 4 m). Die Standardabweichung ist bei beiden Winkeln zwischen 1 und 2 m nahezu konstant, während sie danach annähernd linear zunimmt (60 ° wieder etwas schlechter).

Abbildung 7: Auflösung des ToF Sensors

Empfindlichkeit des ToF Sensors

Die Empfindlichkeit des Sensors beträgt laut 0,14 A/W bei einer Wellenlänge von 860 nm.

Signalverarbeitung des ToF Sensors

Abbildung 8: MIPI Interface der SoCs

Der eigentliche ToF Sensor besteht nicht nur aus dem CMOS Pixel Array, sondern enthält auch die gesamte Signalverarbeitungskette. Es handelt sich also um ein System-on-Chip (SoC). Der Ausgang des SoCs ist realisiert über ein MIPI D-Phy (Master), das mit einem anderen SoC, dem Kamera SoC über das PCB verbunden ist. PHY ist die Abkürzung für Physical Layer (Bitübertragungsschicht des OSI-Modells) und ist ein Verbindungsprotokoll. Ein MIPI D-Phy ist ein PHY der MIPI Alliance für Verbindungen von Kameras und Displays zu einem Applikationsprozessor. Die Schnittstelle die zwischen beiden SoCs benutzt wird ist das sogenannte CSI (Camera Serial Interface), also eine serielle Schnittstelle. Das Kamera SoC empfängt die Daten über ein MIPI D-Phy (Slave), konvertiert sie in den USB Standard und gibt die Daten über den USB 3.0 Bus an den Rechner weiter. Alle Chipdaten sind über 2 4- Lane MIPI D-Phy Schnittstellen angebunden mit einer gesamten Übertragungsrate von 8 Gb/s. Die einzelnen Lanes sind 8b10b codiert. Dabei werden 8 Bit Daten mit 10 Bit kodiert, sodass zum einen ein Gleichspannungsausgleich gewährleistet ist und zum anderen Taktrückgewinnung aus dem Datensignal möglich ist. Das Datenvolumen erhöht sich um 25 %. Der erzeugte Datenstrom enthält daher einen Overhead von 20 % . Wie die Konvertierung MIPI-USB realisiert wird ist nicht bekannt. Die Abbildung zeigt das Blockschaltbild der Verbindung der beiden SoCs.

Die Abbildung unten zeigt das Blockschaltbild des Sensorchips. Sowohl prozesstechnisch als auch schaltungstechnisch handelt es sich um einen sehr komplexes Design, das hier nur in Kürze beschrieben werden kann. Der interessierte Leser sei auf verwiesen. Das Sensorfeld besteht aus 512 Spalten und 424 Zeilen. Jedes Pixel besteht aus zwei Photodioden. Wenn eine Photodiode leitend wird, wird das Licht in Strom gewandelt, das über längere Zeit integriert wird. Die Dioden werden durch zwei Clocks schnell an- und abgeschaltet, so dass wenn eine Diode an ist die andere aus ist. Für jedes Frame wird das Licht gemessen, indem die Differenz der Ausgangsspannungen zwischen den beiden Dioden gemessen wird. Dies wird von den Entwicklern als Quanteneffizienzmodulation (QEM) bezeichnet. Die QEM extrahiert die Phase des oben erwähnten modulierten Signals. Zusätzlich benutzt die Kinect eine sog. Multi-Shutter-Engine, die das Risiko der Sättigung der Dioden minimiert. Hierfür werden verschiedene Verschlusszeiten benutzt und die längste Verschlusszeit, die nicht in einer Sättigung resultiert, wird gewählt als Ausgang für das Pixel. Das Pixelarray ist in eine obere und untere Hälfte aufgeteilt, die jeweils mit einem anderen Takt betrieben werden. Das heißt, dass die Pixelausgänge der oberen und unteren Hälfte separat ausgelesen werden. Ein interner Oszillator treibt den Taktgenerator, der den Pixeltakt und den Takt für das Moulationssignal generiert. Die Takte sind programmierbar. Programmierbare Differenzverstärker (PGA:programmable gain differential apmplifier), jeweils 512 für die obere und untere Hälfte, bereiten die Signale der Arrays auf, gefolgt von Abstaste/Haltekondensatoren. Die Ausgänge von vier angrenzenden PGAs werden gemultiplext in 256 10 Bit ADCs (128 vom oberen und 128 vom unteren Pixelarray). Die Wandler, die nach dem SAR-Prinzip arbeiten, haben eine Konversionsrate von 8 MS/s. Daraus ergibt sich eine Zeilekonversionnsrate von 2GS/s. Darauf folgt die eingangs erwähnte Shutter-Engine. Die Shutter Engine schreibt die Ergebnisse in ein FIFO I/O Buffer RAM. Der Ausleseblock liest dann die Ergebnisse aus dem RAM, konvertiert die Daten in Pakete und schickt diese an die MIPI Hochgeschwindigkeitsschnittstelle.

Abbildung 9: Blockschaltbild des Sensor SoCs

Wahl des A/D-Konverters

Abbildung 10:Prinzip der sukzessiven Approximation

Wie erwähnt nutzt die Kinect A/D-Konverter nach dem Prinzip der sukzessiven Aprroximation. Für die Wahl des Konverters sprechen im Wesentlichen drei Punkte:

1. Hinreichend schnelle Wandlung
2. Ausreichend hohe Auflösung
3. Geringer Platzbedarf

Da die Sensorfläche schon extrem groß ist, würde ein Konverter mit großem Flächenbedarf den Chip noch größer und damit noch teurer machen. Damit würde ein Flash-Umsetzer, der 2^N-1 Komparatoren/OP benötigt, nicht in Betracht kommen, da insgesamt 256 10 Bit ADCs gebraucht werden. Ferner steigt durch die hohe Anzahl an Komparatoren/OPs die Verlustleistung exponentiell an. Dies hätte wiederum Folgen für den Floorplan des Chips. Es müssten mehr Supplypads (Power und Ground) eingefügt werden, um genügend Strom zur Verfügung zu stellen, was den Chip eventuell (abhängig davon ob das Design pad- oder core limited ist) noch größer machen würde. Ein zu langsames Verfahren wie z. B. U/f- oder Dual-Slope-Wandler käme ebenfalls nicht in Betracht. Es muss letztendlich ein Kompromiss geschlossen werden, der allen Punkten gerecht wird, und da ist ein ADC nach dem SAR-Prinzip eine geeignete Wahl, denn ein SAR hat u.a. folgende Eigenschaften :

1. Es werden lediglich ein S&H Glied, ein Komparator, ein DAC, Steuerlogik und Approximationsregister benötigt
2. Auflösung ist mittelgroß (bis zu 12 (16) Bit)
3. Wandlungszeit steigt linear mit der Auflösung

Tiefenbild und Punktwolke

Die folgenden Bilder zeigen beispielhaft wie ein Tiefenbild, eine Punktwolke und das reale Objekt aussehen. Als Beispiel dient eine Yoshi-Figur. Das Tiefenbild ist das direkt von der Kinect erzeugte Bild mit Tiefeninformationen. Mittels der in Matlab verfügbaren point cloud library kann eine Punktwolke erstellt werden. In der point cloud library gibt es den pcfitplane Befehl, mit dessen Hilfe Ebenen oder andere Geometrien in der Punktwolke gefunden und isoliert werden können. Mit genau diesem Ansatz wird im Progamm (siehe Abschnitt Programmablaufplan) das Objekt/Hindernis detektiert und gemessen. Der pcfitplane Befehl basiert auf dem sogenannten MSAC/RANSAC Algorithmus, der hier näher erläutert wird.

• Tiefenbild, Punktwolke, reale Figur
• 

  Abbildung 11: Tiefenbild

• 

  Abbildung 12: Punktwolke

• 

  Abbildung 13: Reale Figur

Realisierung

Das Kapitel beschreibt welche Hard- und Software für die Implementierung benutzt wurde, wie der Aufbau realisiert wurde,den Programmablaufplan und den Signalflussplan.

Verwendete Hardware

• Lego Mindstorms EV3 Brick
• Kinect V2
• Laptop Acer Aspire E15 (8GB RAM, Intel Core i5-6267U @ 2.9Ghz bis zu 3.3 GHz (Turbo Speed))

Verwendete Software

• MS Windows 10 Version 1607
• Kinect for Windows Runtime v1.6
• Matlab R2016b
• Matlab Addons:
  • KEV3 version 1.15 by Liviu Ivanescu
  • QUT toolkit: https://wiki.qut.edu.au/display/cyphy/QUT+EV3+MATLAB+toolkit
  • Image Acquisition Toolbox version 5.1
  • Image Acquisition Toolbox Support Package for Kinect for Windows Sensor version 16.2.0
  • MATLAB Support Package for LEGO MINDSTORMS EV3 Hardware version 16.2.0
  • Computer Vision System Toolbox version 7.2

Aufbau

Abbildung 12: Realer Aufbau des Systems

Abbildung 11: Schematischer Aufbau des Systems

Um die Kinect auf dem Fahrzeug zu befestigen wurde eine kleine Holzplatte gesägt. Da die Kinect an der Unterseite ein Stativgewinde besitzt, wird dieses mittels Stativschraube am Holz befestigt. Zwei weitere Schrauben sorgen für Halt am Fahrzeug (vgl. Abbildung). Die Kinect ist über den USB Bus an den Laptop angeschlossen. Zusätzlich benötigt sie eine 230V Spannungsversorgung. Damit ist die Mobilität des Aufbaus recht eingeschränkt, allerdings ist sie ausreichend, um die Funktionalität zu zeigen. Sämtliche Steuerbefehle an den Brick werden über eine zuvor aufgebaute Bluetooth Verbindung zwischen Laptop und Brick realisiert wie in der Abbildung zu erkennen ist. Da die Kinect nicht bündig mit den Vorderreifen abschließt, muss ein Versatz addiert werden. In diesem Fall wird ein Wert von 4 cm gewählt (nach Messung), der zu den 70 cm addiert wird.

Programmablaufplan

Die folgende Abbildung zeigt den Programmablaufplan: Er beginnt mit dem Aufräumen des Workspaces und dem Initialisieren der Variablen. Es folgt die Erstellung eines Brick Objektes und der Aufbau der Bluetooth Verbindung zwischen PC und Brick. Danach werden die Kinect Kameras initialisiert und entsprechende Videoobjekte erstellt. Der Brick wird gestartet und danach in einer While-Schleife permanent der Abstand zum Hindernis ermittelt. Sobald eine definierte Distanz erreicht wird, wird der Brick zur Notbremsung veranlasst und die While-Schleife verlassen. Im Detail passiert in der Schleife Folgendes: Zuerst wird jeweils ein Tiefenbild erstellt. Danach kommt der erste Filteralgorithmus, der ähnlich wie ein Bandpass arbeitet, d.h. es werden nur Signale eines bestimmten Frequenzbandes, in diesem Fall Bildbereich, durchgelassen. Da der Sensor nur von 0.5 m bis 4.5 m zuverlässig arbeitet, werden alle z-Werte größer 4.5m und kleiner 0.5m gefiltert, d.h. auf null gesetzt. Danach wird das Sichtfeld (FoV) in x- und y-Richtung eingeengt, um irrelevante Daten zu entfernen. Als nächstes wird mit dem Befehl „pcfromkinect“ eine Punktwolke vom Tiefenbild erstellt. Zuletzt wird das Objekt (Hindernis) mittels „pcfitplane“ Befehl aus der Punktwolke isoliert. Von dem isolierten Objekt kann die aktuelle Distanz in z-Richtung ermittelt werden und dann mit der Referenzdistanz für die Notbremsung verglichen werden. Ist der Wert kleiner oder gleich dem Referenzwert, wird eine Notbremsung durchgeführt, sämtliche Objektinstanzen gelöscht und die While-Schleife beendet. Ist der Wert größer als der Referenzwert, geht die Schleife in die nächste Iteration.

Abbildung 13: Programmablaufplan für die Notbremsung

Signalflussplan

Obwohl die gesamte Signalverarbeitung in Software implementiert ist, zeigt die folgende Abbildung den Signalflussplan, der für jedes Frame bis zur Notbremsung durchlaufen wird.

Abbildung 14: Signalflussplan

Darstellung der Ergebnisse

Mögliche Fehler in der Signalverarbeitungskette

Da die Messdaten bereits im Sensorchip in ein digitales Format gebracht werden, können außerhalb keine weiteren hinzukommen (sieht man von Signalverfälschungen durch Übersprechen, Glitches oder Busfehler o.ä. ab). Auf dem Sensorchip können beispielsweise folgende Fehler passieren:

1. Bei der Tiefenmessung
   • Kantenrauschen (Edge-Noise) des Tiefensensors
   • Übersprechen auf ein anderes Pixel (ist allerdings durch Abstand und Dotierung minimiert)
   • Reflektierende/spiegelnde Oberflächen können zu Fehlern in der Tiefenmessung führen
2. Bei der A/D-Konversion
   • Quantisierungsfehler
   • Amplitudenfehler
   • Linearitätsfehler
   • Phasenfehler
   • Quantisierungsrauschen

Messfehler wurden bereits weiter oben diskutiert.

Das Ergebnis des Projektes wurde ferner in einem Video festgehalten, das unter folgendem Link zu erreichen ist:

https://youtu.be/Ex-KgOV4YVA

Die Zeitdauer der einzelnen Schritte kann mittels der Variable "measurePerformance" gesetzt werden. Dann wird zwischen den wichtigsten Sequenzen der Matlabbefehl "tic-toc" verwendet. Die Werte werden auf das Matlab Command Window ausgegeben. Die Initialisierung der USB Verbindung und das Einrichten des Videoobjektes dauert tpyischerweise zwischen 10 und 15 Sekunden. Die Ermittlung der aktuellen Distanz in etwa 200 ms.

Projektplan

Um die Übersicht über das Projekt zu behalten, wurde ein Projektplan mit MS Project 2016 erstellt. Das folgende Bild zeigt den Plan in Form einer Zeitachse.

Abbildung 15: Projektplan in Zeitachsenform

Lessons Learned

• Es ist besser Matlab nach jedem Run zu beenden und neuzustarten. Anderenfalls kann es sein, dass ein Objekt, das vorher erkannt wurde, im neuen Lauf nicht mehr erkannt wird und demzufolge eine Kollision stattfindet. Eventuell werden einige Objekte, die erzeugt wurden trotz "Zerstörung" nicht beendet und werden nicht richtig initialisiert.
• Es konnte selbst nach stundenlangen Versuchen keine Bluetooth Verbindung zwischen Brick und Laptop hergestellt werden. Die Lösung lag hier daran, im Brick den iPhone/iPad Support zu deaktivieren!

Quellen/Referenzen

!!!Für SVN Ordner sind die entsprechenden Zugriffsrechte erforderlich!!!

→ zurück zum Hauptartikel: Signalverarbeitende Systeme SoSe2017