Entwicklung eines autonomen Überwachungssystems DIPLOMARBEIT zur Erlangung des akademischen Grades Diplom-Ingenieur im Rahmen des Studiums Masterstudium Visual Computing eingereicht von Adis Buturovic, BSc. Matrikelnummer 0125423 an der Fakultät für Informatik der Technischen Universität Wien Betreuung Betreuer/in: Univ.Prof. Dipl.-Ing. Dr.techn. Christian Breiteneder Mitwirkung: Dr.techn. Dipl.-Ing. Matthias Zeppelzauer Wien, 08.08.2016 (Unterschrift Verfasser) (Unterschrift Betreuer/in) Technische Universität Wien A-1040 Wien  Karlsplatz 13  Tel. +43-1-58801-0  www.tuwien.ac.at Die approbierte Originalversion dieser Diplom-/ Masterarbeit ist in der Hauptbibliothek der Tech- nischen Universität Wien aufgestellt und zugänglich. http://www.ub.tuwien.ac.at The approved original version of this diploma or master thesis is available at the main library of the Vienna University of Technology. http://www.ub.tuwien.ac.at/eng Erklärung zur Verfassung der Arbeit Hiermit erkläre ich, dass ich diese Arbeit selbständig verfasst habe, dass ich die verwendeten Quellen und Hilfsmittel vollständig angegeben habe und dass ich die Stellen der Arbeit – ein- schließlichTabellen, KartenundAbbildungen–, die anderenWerkenoder dem Internet imWort- laut oder demSinn nach entnommen sind, auf jeden Fall unter Angabe der Quelle als Entlehnung kenntlich gemacht habe. Ort, Datum, Unterschrift Abstract Video and audiomonitoring systems areused across the globe to observe certain events andpro- cesses. Usually, such systems are connected to a communications network and electricity grid and are not equippedwith any kind of processing logic (“intelligence”) other than data compres- sion. How can such systems be used if there is no electricity nor a broadband communications network available? The aim of this thesis is to develop an autonomous monitoring system built entirely from commercially-available standard components, which can operate independently. The 󰅮irst step to achieve this is to conduct a pre-evaluation of existing hardware and software components according to various criteria. The next step involves the development of a hard- ware prototype as well as the implementation of an ef󰅮icient and modular software framework that can be adapted for different applications. The system should support policy-based record- ing modes such as modes controlled by input data from de󰅮ined sensors, like motion and light sensors, that make autonomous decisions about the use of available resources. The software framework should be designed to support the integration of image processing algorithms to al- low pre-processing of recorded (video) data on board in order to save bandwidth. In the 󰅮inal prototype, both the recording of audio and video (among other) data was realized to the desired extent. Using an application, the recording mode can be set easily using a XML con󰅮iguration 󰅮ile. Thepower consumptionof the build system is, depending onused sensors and executed tasks, between 0.68 to 1.75 watts and lies within the range of comparable commercial solutions, such as “leanXcam”. 2 Zusammenfassung Weltweit werden Überwachungssysteme (z.B. mit Kameras und Mikrofonen) eingesetzt, um bestimmte Ereignisse und Umgebungen zu beobachten. Diese werden üblicherweise an ein Kommunikationsnetz und Stromnetz angeschlossen und beinhalten keine eigene Verarbei- tungslogik (“Intelligenz”). Wie verfährt man jedoch, wenn weder Strom noch ein Breitband- Kommunikationsnetz zur Verfügung stehen? Das Ziel dieser Diplomarbeit ist es, ein autonomes Überwachungssystem basierend auf handelsüblichen Komponenten zu entwickeln, das mög- lichst autonom und unabhängig agieren kann und wenige Abhängigkeiten nach außen hat. In der Arbeit wird zunächst der Auswahlprozess von Hard- und Software anhand verschiede- ner Kriterien beschrieben. Der Hauptteil der Arbeit umfasst die Entwicklung eines Hardware- Prototypen sowie die Implementierung eines leistungsfähigen und modularen Software- Frameworks, das unterschiedliche Einsatzzwecke ermöglichen soll. Das fertige System soll re- gelbasierte Aufnahme-Modi unterstützen, beispielsweise gesteuert durch Eingangsdaten von Bewegungs- und Lichtsensoren und basierend darauf autonom Entscheidungen über den Um- gang mit den vorhandenen Ressourcen treffen. Das entwickelte Software-Framework soll die Integration von Bildverarbeitungsalgorithmen unterstützen, um eine Vorverarbeitung der Ka- meradaten im Überwachungssystem selbst zu ermöglichen und Bandbreite zu sparen. Sowohl die Audio- als auch Videoaufnahme wurde im gewünschten Umfang realisiert. Die Kon- 󰅮iguration des Systems kann bequemmittels einer XML-Kon󰅮igurationsdatei durchgeführt wer- den. Der Stromverbrauch liegt bei dem entwickelten System je nach Aufgabenstellung und den verwendeten Sensoren zwischen 0,68 und 1,75 Watt und liegt somit im Bereich von vergleich- baren kommerziellen Lösungen, wie beispielsweise “LeanXcam”. 4 Inhaltsverzeichnis 1 Einführung 9 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.2 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.3 Anwendungsszenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.3.1 Anforderungen an das System . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.4 Beitrag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.5 Au󰅮bau und Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2 Hintergrund und verwandte Arbeiten 19 2.1 Verwandte Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2 Kommerzielle Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2.1 Viseum IMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.2.2 LeanXcam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2.3 Elphel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.3 Mikrokontroller bzw. “System-on-a-Chip”-Komponenten . . . . . . . . . . . . . . 24 2.3.1 CMUcam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.3.2 Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.3.3 Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.3.4 BeagleBone / BeagleBone Black . . . . . . . . . . . . . . . . . . . . . . . . 27 2.3.5 Mehr-Kern SoC-Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.4 Vergleich unterschiedlicher Hardwareplattformen . . . . . . . . . . . . . . . . . . 29 2.5 Sensorik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.5.1 Video . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.5.2 Audio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5 2.5.3 Distanz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.5.4 Bewegung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.5.5 Helligkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.5.6 Echtzeituhr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.6 Entwicklungsumgebungen und Bibliotheken . . . . . . . . . . . . . . . . . . . . . 35 2.6.1 Bibliotheken für maschinelles Sehen . . . . . . . . . . . . . . . . . . . . . . 35 2.6.2 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3 Ansatz und Implementierung 41 3.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.2 Vorevaluierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.2.1 Stromverbrauch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.2.2 Vergleich der Hardware-Plattformen . . . . . . . . . . . . . . . . . . . . . . 46 3.3 Auswahl der Hardware und Software . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.3.1 Betriebssystem und Programmiersprache . . . . . . . . . . . . . . . . . . 48 3.3.2 Video und Audio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.3.3 Echtzeituhr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.3.4 Bewegung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.3.5 Helligkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.3.6 Distanz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.3.7 Auswahl der Programmierbibliotheken . . . . . . . . . . . . . . . . . . . . 50 3.4 Hardwarearchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.5 Softwarearchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.5.1 Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.5.2 Herausforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.6 Kon󰅮iguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4 Evaluierung und Ergebnisse 65 4.1 Videoaufnahme und Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.1.1 Rolle der OpenCV-Bibliothek . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.2 Audioaufnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.3 Bewegungserkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.4 Distanzmessung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 6 4.5 Helligkeitsmessung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.6 Nutzung der Sensoren im Software-Framework . . . . . . . . . . . . . . . . . . . . 70 4.7 Echtzeituhr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.8 Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.9 Stromverbrauch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.9.1 Messverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.9.2 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 5 Zusammenfassung 79 5.1 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 5.2 Grenzen des Systems und Erweiterungsmöglichkeiten . . . . . . . . . . . . . . . . 81 Abbildungsverzeichnis 83 Tabellenverzeichnis 85 Literaturverzeichnis 87 7 8 Kapitel 1 Einführung 1.1 Motivation Überwachungssysteme werden eingesetzt, um bestimmte Ereignisse und Prozesse festzuhal- ten und auszuwerten. Solche Systeme bestehen generell aus einer Eingabe-Einheit (z.B. Kame- ra) sowie einer getrennten Datenverarbeitungseinheit (wie beispielsweise in [Kruse 98] und [Bautista Saiz 14]). Die Kamerawird üblicherweise an ein Kommunikationsnetz bzw. Stromnetz angeschlossen und dient im Falle einer Videoüberwachung rein der Bildakquisition, d.h. hierbei wird die Information entweder nur weitergereicht oder muss noch zusätzlich gespeichert wer- den. Unabhängig davon, ob ein oder mehrere Bilder aufgenommen werden sollen (Foto oder Video), kann eineWeiterverarbeitung der Daten auf der Kamera selbst nur zumNutzen der Ver- ringerung der Datenmenge bzw. Bandbreite durchgeführt werden [Sasson 91]. Die aufgenom- menenDatenwerdendabei auf einem lokalen oder entfernten Speichermediumgespeichert und nachträglich von einemweiteren, unter Umständen zeitlich bzw. geogra󰅮isch separierten System weiterverarbeitet bzw. analysiert. Im Falle einer geogra󰅮isch entfernten Verarbeitung ist es not- wendig, den entsprechenden Speicherplatz sowie eine entsprechende Übertragungsbandbreite zur Verfügung zu stellen. Neben dem Aspekt der Datenspeicherung sind die meisten Überwachungssysteme dauerhaft an das Stromnetz angeschlossen und nehmen unabhängig vom Geschehen ununterbrochen auf. Zum einen entsteht dadurch eine sehr große Datenmenge (die es nachträglich zu analysieren gilt) und zum anderen sind diese Systeme auf die externe Stromversorgung angewiesen. 9 Durch die stetig steigende Rechenleistung sowie immer kleiner werdende Hardware ist erkenn- bar, dass die Komponenten eines Überwachungssystems zukünftig verschmelzen werden. Die- se Überlegungen sind die Motivation für die vorliegende Arbeit, deren Ziel es ist, bestehende, vornehmlich preisgünstige Hard- und Softwarekomponenten zu kombinieren, um die Anforde- rungen an die Audio- bzw. Videoaufnahme, Analyse und Weiterverarbeitung der Daten sowie an die Erweiterbarkeit durch Sensoren (z.B. zum Anstoßen der Aufnahme-Prozesse) in einem integrierten System zu vereinen. In weiterer Folge soll die prototypische Entwicklung eines sol- chen Systems durchgeführt werden. Hierbei soll eine möglichst lange Aufnahme- und Standby- zeit, d.h. geringer Stromverbrauch, erreicht werden, um eine Selbstversorgung, beispielsweise über kleinere Photovoltaik-Anlagen, zu ermöglichen. Bei der Analyse der Daten kann es sich um Gesichtsdetektion [Viola 04], Bewegungsdetektion [Cutler 00] und umdie Realisierung komple- xer Algorithmen,wieObjekterkennung [Viola 01], handeln. Somit könnten die oben angeführten Schritte der Audio- und Videoübertragung und Analyse auf einem entfernten System entfallen bzw. durch eine verteilt statt󰅮indende Vor󰅮ilterung unterstützt werden und Bandbreite gespart werden. 1.2 Problemstellung Existierende Überwachungssysteme benötigen im Allgemeinen eine externe Stromversorgung bzw. eine ausreichend hohe Bandbreite. Wenn dies nicht der Fall ist, sind die angebotenen Lö- sungen rar. Bei einem Verkehrsüberwachungssystem in Regionen mit schwacher Infrastruktur bzw. limitierten Ressourcen, seien es Strom oder eine limitierte Datenübertragungsbandbreite, wäre ein autonomes, selbstversorgendes, vom Benutzer kon󰅮igurierbares System von Vorteil. Dieses könnte durch Bewegungs- oder Ultraschallsensoren getriggert eine Videoaufnahme aus- lösen, bestimmte weitere Merkmale extrahieren (z.B. Kennzeichen) und nur diese Ergebnisse speichern bzw. zu anderen Systemen übertragen. Das Ziel dieser Diplomarbeit ist es, das Potential und die Machbarkeit eines solchen mög- lichst autonomen Überwachungssystems zu evaluieren, Anforderungen zu de󰅮inieren sowie ei- ne preisgünstige “Proof-of-Concept”-Lösung zu entwickeln. Dies umfasst die Evaluierungder am Markt be󰅮indlichen Hardware- und Software-Plattformen, die Entscheidungs󰅮indung und letzt- endlich die Erstellung und Evaluierung eines Prototypen als “Proof-of-Concept”. 10 Die Priorität soll vor allem auf der Video-Aufnahmequalität sowie Verarbeitungsgeschwindig- keit bei niedrigem Stromverbrauch liegen. Erwünscht ist eine Videoaufnahme mit einer mög- lichst hohen Bildwiederholfrequenz in HD-Au󰅮lösung, um beispielsweise bei schnell bewegen- den Objekten genügend Informationen zwischen zwei aufeinanderfolgenden Bildern zu erhal- ten. Auch die Kon󰅮igurationsmöglichkeit durch den Benutzermuss vorhanden sein. Die genauen Anforderungen sind in Unterkapitel 1.3.1 spezi󰅮iziert. UmdieAufnahmeundAuswertungderDaten auf demSystemdurchzuführen, sollen Standardbi- bliotheken bzw. Softwarepakete, die Algorithmen für Bildverarbeitung und maschinelles Sehen bereitstellen, verwendet werden, um von zukünftigen Entwicklungen pro󰅮itieren zu können. Im weiteren Verlauf der Arbeit wird die Untersuchung folgender Fragestellungen und Problemstel- lungen angestrebt: Aufnahme und Analyse • Inwieweit können die Anforderungen der Video- und Audioaufnahme (bezogen auf Ab- tastrate und Au󰅮lösung) erfüllt werden? • In welchen Video- bzw. Audio-Formaten kann eine Aufnahme realisiert werden? • Wie lange kann aufgenommenwerdenbzw.wie kannder Speicherplatz erweitertwerden? • Wie gut kanndie Synchronizität zwischenVideo- undAudiospuren gewährleistetwerden? • Kann zusätzlich zur Video- und Audioaufnahme eine gleichzeitige Datenanalyse ausge- führt werden? Entwicklung und Erweiterbarkeit • Welche Hardware ist notwendig, um die Anforderungen zu erfüllen? • Wie kann eine einfache Kon󰅮iguration des Systems aussehen? Stromaufnahme • Mit welchen Hardware-Plattformen ist die niedrigste Leistungsaufnahme zu erwarten? 11 • Mit welchem Stromverbrauch muss bei der Verwendung mehrerer Eingabequellen sowie den zu erwartenden Hintergrund-Prozessen (z.B. nachträgliche Video-Komprimierung oder Bewegungsdetektion) gerechnet werden bzw. kann dies bei der “Proof-of-Concept”- Lösung eingehalten werden? Weiters soll ein leicht erweiterbares, unter MIT-Lizenz [Mas 15]) quelloffenes Software- Framework entwickelt werden. Obwohl eine geringe Stromaufnahme eine wichtige Anfor- derung darstellt, ist die Entwicklung einer Stromversorgung (z.B. Photovoltaik-Anlage mit Ladeeinheit) kein wesentlicher Punkt dieser Arbeit. Auch rechtliche Aspekte der Video- /Audioaufzeichnungen (z.B. Schutz der Privatsphäre) werden nicht im Rahmen dieser Arbeit behandelt. 1.3 Anwendungsszenario Diese Arbeit ist im Kontext eines Forschungsprojektes entstanden, welches sich mit der visu- ellen und akustischen Überwachung (Monitoring) von Tieren beschäftigt mit dem Ziel deren Verhalten zu analysieren [Zeppelzauer 13]. Speziell in diesem Bereich sind autonome Überwa- chungssysteme notwendig, da im Freiland kaum Infrastruktur existiert. Autonome Systeme für das Monitoring im Freiland gibt es vorwiegend im Audio-Bereich (z.B. SM4 von “Wildlife acou- stics, Inc.” [Wil 16]). Für Videoaufnahmen sind nur sehrwenige, begrenzt kon󰅮igurierbare Syste- me vorhanden, die weder Datenanalysen “on-the-󰅮ly” ermöglichen noch für den Einsatz im Feld aufgrund notwendiger externer Stromversorgung geeignet sind. Das Ziel dieser Arbeit ist es, ein solches System vor allem für den Zweck der Tierbeobachtung zu entwickeln. Sowohl für die Evaluierung der bestehenden Systeme, als auch für die Erstellung der Anforderungen und der “Proof-of-Concept”-Lösungwird einemöglichst stromsparende Lösung benötigt. ImKontext des Forschungsprojektes, welches dieser Arbeit zugrunde liegt, wurden folgende Anwendungsfälle für die Tierbeobachtung de󰅮iniert, welche mit dem prototypisch umgesetzten Überwachungs- system evaluiert werden sollen. • Anwendungsfall 1: Eine nahezu durchgehende Videoaufzeichnung bei Tageslicht (Bild- wiederholfrequenz und Au󰅮lösung sollen an Strom-/Platzverbrauch angepasst werden) und in der Nacht nur eine Audioaufnahme bei durch Sensoren erkannter Bewegung (z.B. Bewegungs- oder Ultraschallsensor). Dies würde sich eignen, um die Präsenz von Tieren 12 zu bestimmen. • Anwendungsfall 2: Eine Video-Trigger gesteuerte Aufnahmemit beispielsweise einer Fre- quenz von einem Bild pro Sekunde und einem Objekt-Erkennungsalgorithmus, der eine Video- undAudioaufzeichnung auslöst, solange Objekte erkanntwerden. Hiermit kann so- wohl die Präsenz als auch das Verhalten einer bestimmten Tierart (z.B. Elefanten) analy- siert werden. • Anwendungsfall 3: Durchgängige Videoaufzeichnung imZeitraffer-Modus (beispielsweise alle fünf Minuten ohne nachträgliche Datenanalyse). Dieser Fall eignet sich, um besonders lange und stromsparend Aufzeichnungen durchzuführen. Beispielsweise kann ein solches System über Tage autonom aufnehmen. In allen Fällen ist eine Vielzahl von Entscheidungen notwendig. Anwendungsfall 1 wird im fol- genden Flussdiagramm (Abbildung 1.1) vereinfacht dargestellt. Weitere Anwendungsmöglichkeiten eines solchen autonomen Überwachungssystems, die über Tierbeobachtung hinausgehen, sind vielfältig. Generell wird hierbei an eine Überwachung von öffentlichen Plätzen gedacht, dazu zählen beispielsweise Verkehrsüberwachung und Personen- beobachtung. Bei der Verkehrsüberwachung kann von einer kontinuierlichen Videoaufnahme ausgegangen werden. Gleichzeitig könnte bei Erkennen eines Fahrzeugs (durch Algorithmen der Objekter- kennung) ein Trigger-Mechanismus die Speicherungweiterer Sensordaten (beispielsweise Sen- soren, die eine Entfernungsmessung durchführen) auslösen. Auch bei der Personenüberwachung könnten durch Gesichtserkennungsalgorithmen diverse darauf folgende Mechanismen ausgelöst werden, wie zum Beispiel eine Audioaufnahme. 1.3.1 Anforderungen an das System Für die Entwicklung der “Proof-of-Concept”-Lösung wurden unter Betrachtung unterschiedli- cherMonitoring-Szenarien folgendeMindestanforderungen festgelegt. Detaillierte Anforderun- gen werden nach der Evaluierung der Entwicklungsumgebungen und ähnlicher Systeme in Un- terkapitel 3.1 ergänzt. 13 Start Tageslicht vorhanden? Konfiguration einlesen Status der Module auslesen Aufnehmen Aufnehmen Bewegung vorhanden? Platz vorhanden? Ja Nein Ja Nein Ja Stop Platz vorhanden? Nein JaNein Abbildung 1.1: Flussdiagramm - Anwendungsfall 1 Generelle Anforderungen • Die Aufnahme soll durch verschiedene Sensoren ausgelöst werden können. Unabhängig vom “Trigger-Sensor” sollen Audio-, Video-, Distanz-, Bewegungs- und Helligkeitsdaten möglichst energiesparendaufgenommenwerden.DieUmsetzungder Sensorenbzw. Funk- tionen wird in Tabelle 1.1 dargestellt. • Eine softwareseitige, durch Datenanalyse ausgelöste Triggerung soll möglich sein. 14 • Die Übertragung von Daten (bzw. Ergebnissen) soll über das TCP/IP-Protokoll erfolgen. Die Möglichkeit einer Mobilfunk-basierenden Datenübertragung soll gegeben sein. • Die Speicherung der Daten soll auf einem auswechselbaren, externen Datenträger erfol- gen. • Die Datenanalyse (z.B. Objekterkennung) soll mit gängigen Bibliotheken zum maschi- nellen Sehen erfolgen (wenn nicht in Echtzeit möglich, dann asynchron durch einen Queueing-Mechanismus). • Das Versetzen des Systems in Energiesparmodus soll auch von der Software gesteuert möglich sein. • Das System soll kompakte Maße (max. 25 cm x 25 cm) besitzen und preisgünstig sein (im Bereich zwischen 200€ und 300€). • Das zu erstellende Software-Framework soll leicht erweiterbar sein. Sensor Aufnahme Triggerung Anmerkung zur Umsetzung Audio + - Einkanal-Aufnahme. Mindestens eine 16 Bit Au󰅮lösung. Video + + Triggerung durch benutzerde󰅮inierte Algorithmen zur Objekterkennung. Mindestau󰅮lösung von 640 x 480, 10 FPS. Einzelbilder in der HD-Au󰅮lösung von 1280 x 720 Pixel. Kamera soll eine Weitwinkel-Optik (Bildwinkel im Bereich zwischen 75° und 120°) sowie optional einen Auto-Fokus besitzen. Distanz + + Umsetzung z.B. durch einen Ultraschallsensor. Bewegung + + Umsetzung z.B. durch einen Infrarot-Bewegungsmelder. Helligkeit + + Umsetzung z.B. durch einen Fotowiderstand. Zeit + + Durch den Zeitpunkt de󰅮inierte Aufnahme. Tabelle 1.1: Benötigte Sensoren Anforderungen an die Stromaufnahme • Die maximale Leistungsaufnahme soll so gering wie möglich sein, um eine autonome Be- nutzungmittels Akku/Batterie (bzw. Photovoltaik-Anlage) zu ermöglichen. Genaue Kenn- zahlen werden nach der Analyse verschiedener Hardwareplattformen festgelegt (siehe 15 Kapitel 3.1). Anforderungen an die Software-/Hardwareplattform • Multithreading-Unterstützung. • Audioaufnahme in Echtzeit. • Videoaufnahme in Echtzeit. • Videoverarbeitung mittels gängiger Bibliotheken zummaschinellen Sehen (wenn nicht in Echtzeit möglich, dann durch einen Queueing-Mechanismus). • Einstellbare Aufnahmezeiten (Start/Stopp) sowie einstellbare Intervalle der Sensoren (bei einer Videoaufnahme zusätzlich die Au󰅮lösung). • AutonomeAufnahmebei derAuslösung durch einenTrigger-Mechanismus (z.B. durch den Bewegungsmelder). • Hardware soll zusätzlich gesteuert in Ruhe- bzw. Sparmodus versetzt werden (z.B. CPU- Frequenz abhängig vom erwarteten Aufwand). • Optional: Entfernte Kon󰅮iguration und Datenübertragung (z.B. Nachrichtenversand beim Auftreten eines Ereignisses). Die Erfüllung (sowie Bewertung) der hier festgelegten Anforderungen wird in Kapitel 4 evalu- iert. 1.4 Beitrag In dieser Arbeit wird, wie in Kapitel 1.2 erläutert, die Entwicklung eines Überwachungssystems präsentiert, das neben den Standardaufgaben, wie Video-/Audioaufnahme und Speicherung von Sensordaten, auch eine Auswertung und Vor󰅮ilterung der Daten ermöglicht. Die durchgän- gige Kon󰅮igurierbarkeit (bzw. Auswahlmöglichkeit) der Trigger sowie der Aufnahmesensoren ist ein Alleinstellungsmerkmal dieses Systems. Bei der Auswahl der Komponenten, sowohl im Bereich der Hardware als auch Software, sollen vornehmlich Open-Source-Entwicklungen ver- 16 wendet werden, um in weiterer Folge die Erkenntnisse dieser Arbeit im Rahmen eines Gesamt- Frameworks zur Verfügung zu stellen. Bestehende Komplettlösungen sind entweder nicht leistungsfähig genug, bieten keine Möglich- keit der Datenauswertung direkt in der Kamera, sprengen den angesetzten Budgetrahmen (bei- spielsweise Elphel [Elphel, Inc. 15c], Kosten ca. 800€), vor allemKamerasystememit hoher Au󰅮- lösung werden nicht mehr hergestellt bzw. unterstützt (LeanXcam [LeanXcam 08]) und unter- stützen die Aufnahmemehrerer Sensoren nicht. Bei bestehenden Komplettmodulen fürmaschi- nelles Sehenmit eingebautemWebinterface fehlen außerdemzusätzlicheErweiterungsmöglich- keiten. 1.5 Au󰅯bau und Organisation Die Arbeit ist in fünf Kapitel gegliedert. In Kapitel 1 werden Motivation, Problemstellung und Anwendungsszenario erläutert. Es folgt eine Analyse verfügbarer Lösungen aus Forschung und Wirtschaft, das sind Komplettsysteme, die in Konkurrenz zu diesem Thema gesehen werden können, deren Vor- und Nachteile, eine Evaluierung der zur Verfügung stehenden Hardware- Entwicklungsplattformen sowie die Evaluierung der Software-Entwicklungsumgebungen im Bereich Bildverarbeitung und maschinelles Sehen. In Kapitel 3 werden die Anforderungen detailliert aufgeführt sowie die Evaluierung und Aus- wahl geeigneter Hard- und Software bzw. Softwarebibliotheken durchgeführt. Weiters wird die Architektur der Software beschrieben und eine Beschreibungssprache de󰅮iniert, die der Kon󰅮i- guration des Systems dienen soll. Das letzte Kapitel fasst diewesentlichen Ergebnisse imHinblick auf de󰅮inierte Zielsetzungen zu- sammen, erläutert Stärken und Schwächen des Systems und wirft abschließend einen Blick auf zukünftige Entwicklungen und mögliche Erweiterungen. Im Anhang ist neben den Verzeichnis- sen auch eine Dokumentation der Implementierung sowie das Application Programming Inter- face (API) zu 󰅮inden. 17 18 Kapitel 2 Hintergrund und verwandte Arbeiten 2.1 Verwandte Arbeiten Hier werden ähnliche Projekte bzw. Eigenentwicklungen mit ähnlichen Problemstellungen auf- gezeigt. Ein Videoüberwachungssystem, das auf dem Prinzip der reinen Aufnahme ohne Aus- wertung (siehe Kapitel 1.1), jedoch auf einem eingebetteten System basiert, wurde beispiels- weise von Li und Hao [Li 08] beschrieben. Dieses nutzt eine auf ARM-Prozessoren basierende Hardware sowie eine USB-Kamera zur Videoaquisition. Die Aufgabe der Datenanalyse bzw. Aus- wertung wird hier nicht berücksichtigt, sondern nur die Möglichkeit einer Aufnahme mit weni- ger leistungsfähigen ARM-Systemen (verglichen zu handelsüblichen PCs). In der Arbeit von Chianese et al. [Chianese 15] ist ein Beispiel für ein Sensoren-Netzwerk, das auch für Überwachungszwecke verwendet werden kann, beschrieben. Hier wird ein auf Beagle- Bone Black basierendes System als Teil eines Sensor-Netzwerks mit multiplen Knoten benutzt. Es ist weder eine Video- bzw. Audioaufnahme noch eine Auswertung der Daten im Fokus. Viel mehr steht das “Internet of Things” und die Interaktion zwischen verschiedenen, bis jetzt übli- cherweise eigenständigen, nicht vernetzten Komponenten im Vordergrund. Der Ansatz eines Systems, das sowohl audiovisuelle Daten aufnimmt als auch Eingaben vonwei- teren Sensoren ermöglicht, ist die SenseCam [Hodges 06] (Abbildung2.1). Diesewurde für “Life- Logging”-Zwecke entwickelt und in zahlreichen wissenschaftlichen Publikationen erwähnt1. Während die Aufnahme verschiedener Sensordatenmöglich ist (Video, Audio, Beschleunigung), 1Siehe: http://research.microsoft.com/en-us/um/cambridge/projects/sensecam/publications.htm 19 ist die Möglichkeit der Auswertung der Daten sowie eine Kon󰅮iguration des Systems zu diesen Zwecken nicht vorhanden. Auch die Verwendung der SenseCam im Bereich der Tierüberwa- chung wurde nicht evaluiert. Abbildung 2.1: Microsoft Research SenseCam Als Beispiel für eine autonome Kamera mit Stromerzeugung aus Solarzellen und einer Kom- munikationsschnittstelle über Mobilfunk ist die Arbeit von Jens Gabrikowski [Gabrikowski 08] nennenswert, jedoch werden hier nur Standbilder und keine Video-/Audioaufnahmen erzeugt. Das Ziel der Arbeit war, die autonome Überwachung von Flugplätzen mit der Möglichkeit einer externen Kon󰅮igurationmittels eines Mobiltelefons zu realisieren. Als Abgrenzung zu der in die- ser Arbeit angestrebten Lösung, wurde neben der nur langsamen (Time-Lapse) Videoaufnahme auch keine Möglichkeiten zur Auswertung der aufgenommenen Daten vorgesehen. 2.2 Kommerzielle Systeme Generell werden Systeme, die in den technischen Kontext eingebunden sind, als eingebettete Systeme (“Embedded Systems”) bezeichnet. Diese können auf Arbeitsplatzcomputer-ähnlicher Hardware basieren, wobei einige Komponenten leicht abgewandelt sind (beispielsweise wer- den Prozessoren ohne eine MMU (Memory Management Unit) verwendet). Als Betriebssystem wird häu󰅮ig ein angepasstes Linux-Betriebssystem genutzt. Basierend auf eingebetteten Syste- men sind bereits einige Komplettsysteme am Markt erhältlich, die die Anforderungen dieser Arbeit teilweise erfüllen. Diese Komplettsysteme und auch Entwicklungsumgebungen, die für das Erreichen des Ziels verwendet werden können, werden in diesem Kapitel vorgestellt. 20 Unter den kommerziellen Systemen sind vor allemLeanXcamundElphel hervorzuheben, da die- se die meisten Features abdecken und sowohl Software als auch Hardware unter Open-Source- Lizenz verfügbar sind. Beide Kamerasysteme ermöglichen eine Weiterverarbeitung der Daten auf der Kamera-Hardware selbst, da sie die Möglichkeit besitzen in C (bzw. C++) geschriebe- ne Programme auszuführen. Ein weiteres kommerziell verfügbares System von der Firma Vi- seum, die “Intelligent Moving Camera” (IMC), besteht aus mehreren Kameras und verfügt über Objekterkennungs- bzw. Objektverfolgungsfunktionalitäten. 2.2.1 Viseum IMC Bei Viseum IMC (Abbildung 2.2) handelt es sich um ein wetterfestes Außenbereich-Kamera- Array zur multivariaten Szeneerfassung, das für die Überwachung des öffentlichen Raums in England eingesetzt wird. Da das System aus mehreren Kameras besteht, ist es laut demHerstel- ler möglich, einen Bereich zwischen 2 und 135 Metern in jede beliebige Richtung abzudecken [IMC 16]. Die Auswertung der Daten, beispielsweise eine Gesichtsdetektion oder Objektverfol- gung, ist nicht “on-board” sondernmit einem externen Auswertesystemmöglich, jedochwerden kaum technische Einzelheiten bzw. der Preis des Systems bekannt gegeben. Aus diesem Grund wird diese Kamera in der Hardware-Vergleichstabelle nicht angeführt (Tabelle 2.1). Abbildung 2.2: Viseum IMC Kamera-Array 21 2.2.2 LeanXcam Das Open-Source-System wurde speziell für den Bereich des maschinellen Sehens entwickelt und wurde im Jahr 2008 vorgestellt (siehe Abbildung 2.3). Seitdem wird es in verschiedenen Hochschulen bzw. Unternehmen verwendet. Die Kamera ist vorwiegend im Bereich Prozess- überwachung im Einsatz. Als Betriebssystem wird eine für eingebettete Systeme angepasste Linux-Umgebung verwendet - “μClinux”. Die gängigen Algorithmen für maschinelles Sehenwer- den von der an die Kamera angepassten Bibliothek LeanCV zur Verfügung gestellt. Diese in C ge- schriebene Open-Source-Bibliothek unterstützt die gleichen Datentypen, die auch von der weit- verbreiteten Open-Source-Bibliothek OpenCV genutzt werden. Somit ist es möglich, bestehende OpenCV-Entwicklungen auf der LeanXCam zu verwenden. Für die Erweiterbarkeit sind “Gene- ral Purpose”-Eingänge und Ausgänge (GPIO) vorhanden. Die Leistungsaufnahme ist mit unter 500mAbei 5V angegeben,was einemMaximumvon2,5Watt entspricht. Die Kamera besitzt eine Au󰅮lösung von 752 x 480 Pixel und ist imstande Aufnahmen mit 60 Bildern pro Sekunde aufzu- nehmen. Für Audioaufnahmen steht jedoch kein Mikrofon zur Verfügung [Zahn 14]. LeanXcam ist für 351€ erhältlich (Stand 28.02.2016), jedoch wurde die Entwicklung als auchWartung der Kamera im März 2015 eingestellt [LeanXcam 15]. Abbildung 2.3: LeanXcam Open-Source Kamera 22 2.2.3 Elphel Die autonomen Netzwerkkameras der Fa. Elphel (beispielsweise Modell 313 bzw. 353 [Elphel, Inc. 15b]) können ohne zusätzliche Verarbeitungseinheit (z.B. PC) für Aufnahmen so- wohlmit sehr hoherBildau󰅮lösung (2592x1936) als auchmit hoherBildwiederholrate (240FPS bei 320 x 240) eingesetzt werden. Für Überwachungsaufgabenmit Hochsicherheitsansprüchen, die eine hohe Au󰅮lösung erfordern, kann die Kamera dazu eingesetzt werden, um beispielsweise nur einen Teilbereich des aufgenommenenBildes zu verwenden bzw. auchweit entfernte Objek- te zu erkennen. Das Betriebssystem (GNU/Linux) bzw. die gesamte Software be󰅮indet sich auf dem internen Speicher und Aufnahmen können per Netzwerk an ein Subsystem geschickt wer- den. Als Verarbeitungseinheit wird hardwareseitig der “System-on-a-Chip” AXIS Etrax FS Dual- Core Prozessor verwendet, der sowohl eine CPU als auch einen Netzwerk-Kontroller beinhal- tet [Axis Corporation 08]. Sowohl die Software als auch Aufnahme-Hardware sind unter Open- Source-Lizenz verfügbar. Um die Weiterverarbeitung der Daten auf der Kamera selbst durchzu- führen, ist es möglich, in C geschriebene Applikationen direkt auf der Kamera laufen zu lassen. Die Stromversorgung wird aus dem LAN (gemäß IEEE 802.3af-Standard) bezogen. Je nach Spe- zi󰅮ikation werden die Kameras zwischen 789€ und 4529€ angeboten (Stand 27.02.2016). Die Kamera verbraucht je nach Aufgabe (Ruhezustand, Aufnahme bzw. Aufnahme undWiedergabe) zwischen 2,4 und 5,8 Watt [Elphel, Inc. 15a]. Abbildung 2.4: Elphel Model 353 Kamera 23 2.3 Mikrokontroller bzw. “System-on-a-Chip”-Komponenten Es ist eine große Anzahl an Hardware-Kompontenten bzw. Hardwareplattformen vorhanden (über 120, siehe: [Wikipedia 16]) und zwar sowohl Komplett-Umgebungen aus dem Bereich des maschinellen Sehens als auch Hardware-Entwicklungsumgebungen, die für die Umsetzung der gewünschten Anforderungen (beispielsweise Verarbeitung der aufgenommenen Daten) verwendet werden können. Bei Komplett-Systemen bestehend aus einer Kamera (mit CMOS- Sensor bzw. Linse) und einer zusätzlichen Prozessoreinheit, um einfache Erkennungsalgorith- men auszuführen, ist die CMUcam zu nennen. Weitere Hardwareplattformen können entwe- der auf einem Mikrokontroller (z.B. Arduino) oder einem Komplett-System-Chip-basierenden PC-ähnlichen System (“System-on-a-Chip” oder auch als “Single-Board Computer” bezeich- net), beispielsweise BeagleBone oder Raspberry Pi, basieren. Während es für Mikrokontroller- basierende Systeme eine hohe Anzahl an Erweiterungsplatinen gibt, sind die Erweiterungsmög- lichkeiten bei “System-on-a-Chip”- (SoC) Systemen spärlicher. Generell haben Mikrokontroller- basierende Systeme eine deutlich geringere Leistung sowie eine niedrigere Stromaufnahme. Die SoC-Systeme enthalten nahezu alle Hard- und Software-Komponenten eines Linux-Rechners, wie beispielsweise ein Betriebssystem, einen USB-Anschluss oder eine GPU (Graphics Proces- sing Unit) mit HDMI-Anschluss (Raspberry Pi). Folgend werden vielversprechende Plattformen vorgestellt. 2.3.1 CMUcam CMUcam(CMUcamVersion5 -Pixy) stellt eine Software- bzw.Hardware-Enwicklungsumgebung zur Verfügung, die speziell für den Bereich des maschinellen Sehens entwickelt wurde und seit August 2014 auf demMarkt ist. Sie ist aus der Partnerschaft zwischen dem Robotik-Institut der CarnegieMellonUniversität (US)undderFa. CharmedLabs entstanden [Rowe 07].DieCMUcam- Hardware besteht aus einem CMOS-Sensor und einem ARM-Cortex-M4-basierenden Dual-Core Mikrokontroller. Die Software ist unter Open-Source-Lizenz verfügbar und auch die Hardware- Stückliste sowie Schaltung stehen für einenNachbau zur Verfügung. Das Besondere an der CMU- cam ist, dass diese eine Detektion der Objekte selbst durchführen und diesen Output weiterge- ben kann. Eine Detektion der Objekte ist nur über deren Farbe bzw. über sogenannte Farbsigna- turen (“color codes”) möglich. Das bedeutet, dass zwei zuvor festgelegte, nebeneinander auftre- 24 tende Farben als ein Objekt zusammengefasst werden können. Es können sieben verschiedene Farben (Objekte) mit einer Bildwiederholrate von 50 Bildern pro Sekunde erkannt werden. Bei der Verwendung von Farbsignaturen sind es über hundert verschiedene Objekte. Andere Algo- rithmen, zum Beispiel zur Gesichtserkennung, sind noch nicht verfügbar. Aufgrund der relativ leistungsarmen, dafür aberpreisgünstigenHardware ist dieEntwicklungneuerAlgorithmennur schwermöglich und eineVerwendungder frei verfügbarenBibliotheken fürmaschinelles Sehen, wie beispielsweise OpenCV, nicht möglich. Der Stromverbrauch der CMUcamwurdemit 140mA bei 5V (0,7 Watt) angegeben. Eine Kombination mit einer stromsparenderen Mikrokontroller- basierenden Hardwareplattform (beispielsweise Arduino) ist möglich, um neben der Aufnahme und Erkennung (um die sich die CMUcam bereits kümmert) die Erweiterbarkeit (z.B. Audioauf- nahme) zu gewährleisten. Die aktuelle Version der CMUcam kostet 58€ (Stand 27.02.2016). Abbildung 2.5: CMUcam 5 - Pixy 2.3.2 Arduino Die bekannteste Mikrokontroller-basierende Entwicklungsumgebung ist Arduino. Diese basiert auf Atmel-Mikrokontrollern und wurde das erste Mal 2005 von den zwei Entwicklern Massi- mo Banzi und David Cuartielles der Open-Source-Community vorgestellt. Die Taktgeschwindig- keit beträgt je nach Modell typischerweise zwischen 8 und 16 MHz und alle Modelle (mittler- weile über zwanzig verschiedene) können mit einer Spannung von 5V betrieben werden. Die Hauptintention der Arduino-Hardware ist die Steuerung von I/O-Pins. Arduino ist vor allem fürMikrokontroller-Einsteiger und kleinere bismittelgroße Projekte geeignet. Die Programmie- 25 rung erfolgt über die eigene Arduino-IDE und der damit erzeugte Binärcode kann über die IDE auf den Mikrokontroller übertragen werden. Es gibt eine sehr hohe Anzahl an Erweiterungs- platinen (sogenannte “Shields” - beispielsweise für die Motorsteuerung oder Datenspeicherung auf SD-Karten, siehe [Oxer 16]). Eine externe Bibliothek für maschinelles Sehen (z.B. OpenCV) ist zwecks geringer Leistungsfähigkeit nicht vorhanden. Mittlerweile wird seit Ende 2013 auch ein Linux-basierendes System angeboten. Dieses gilt als das teuerste Arduino und wird um 77€ angeboten. Die Leistungsaufnahme der reinen Mikrokontroller-Boards ist jedoch um Faktor 10 geringer (ca. 200mW). Die ursprünglichen Ar- duinos gibt es bereits ab 20€ bzw. Arduino Mini und Nano sind bereits um ca. 10€ erhältlich. Abbildung 2.6: Arduino Mega 2560 2.3.3 Raspberry Pi Das Raspberry Pi ist ein SoC-Rechner, der von der Raspberry Pi Foundation entwickelt wur- de und seit Anfang 2012 am Markt erhältlich ist. Die Hardware besteht je nach Modell (bisher sechs) aus den Broadcom BCM2835 und BCM2836 SoC-Chips [Broadcom Europe Ltd 12], die die meisten Komponenten stellen und zwar unter anderem CPU (Computing Processing Unit), USB-Kontroller, GPU (Graphics Processing Unit), Netzwerk-Kontroller und Audio-Kontroller. Als Betriebssystem kommen zumeist angepasste Linux-Distributionen, beispielsweise “Embedded Linux” (eLinux), zum Einsatz. Beim Stromverbrauchwerden je nach Last undModell Werte zwi- schen 100mA und 800mA bei 5V angegeben (0,5-4 Watt). Die aktuelle Version 2 Modell B wird für 42€ angeboten. Seit 2013 ist ein eigenes Kamera-Modul für die Videoaufnahme erhältlich. 26 Für die Audioaufnahme kann ein Zusatzmodul bzw. eine USB-Soundkarte angeschafft werden. Da es sich umein herkömmliches Linux-basierendes Systemhandelt, kann die Softwareentwick- lung in einer Vielzahl von Programmiersprachen vorgenommen werden, beispielsweise C++ oder Python. Abbildung 2.7: Raspberry Pi Rev. B 2.3.4 BeagleBone / BeagleBone Black Das BeagleBone ist auch ein SoC-Rechner, der auf dem OMAP3530-SoC [Tex 13] von Texas In- struments basiert und Mitte 2011 auf den Markt gebracht wurde. Wie Raspberry Pi, wird die- sesmit einer für SoC-Systeme angepassten Linux-Version ausgeliefert. Jedoch hat das BeagleBo- ne neben den üblichen Ein- bzw. Ausgängen (GPIO), die für Steuerungszwecke verwendet wer- den können, wesentlich mehr Hardware-Funktionalitäten, wie beispielsweise einen Hardware- Timer, I2C-Bus, CAN-Bus sowie auch Analog-Eingänge (mit 12 Bit Analog/Digital-Wandlern) [Coley 13]. Für eine Audio-Verarbeitung (Wiedergabe/Aufnahme) kann außerdem eine eige- ne Erweiterungsplatine (Cape) erworben werden sowie ein Kamera-Cape für Videoaufnah- men. ÜberUSBkönnen sämtlicheUSB-Kameras angeschlossenwerden. Das aktuelle BeagleBone Black wird für 62€ angeboten (Stand 27.02.2016). Auch bei BeagleBone bzw. BeagleBone Black ist bei der Softwareentwicklung eine Auswahl zwischen verschiedenen Programmiersprachen möglich. 27 Abbildung 2.8: BeagleBone Black 2.3.5 Mehr-Kern SoC-Systeme Um eine Vorselektion von Videodaten durchzuführen, sind Bibliotheken zur maschinellen Bil- derkennung notwendig. Als “State-of-the-Art”-Methode für zahlreiche Anwendungen aus der maschinellen Bilderkennung (im Bereich der Klassi󰅮izierung und Erkennung) gelten Systeme mit Unterstützung der Gra󰅮ikkarten-Programmierung, wie beispielsweise der Tegra K1 Chipmit CUDA-Unterstützung. Was die Leistungsaufnahme von solchen Systemen betrifft, wurden zum Beispiel bei dem von Professor Andrew Ng ins Leben gerufenen “Google Brain”-Projekt noch 1000 Server und600kWatt benötigt, umeinemaschinelle Bilderkennungmittels neuralenNetz- werken (“Deep Neural Networks”) durchzuführen [Le 13] [Matsugu 03] [Krizhevsky 12]. Mitt- lerweile gibt es die “Low-Power Image Recognition”-Herausforderung2, bei der diese Aufgaben- stellungen mit einem Tegra K1, 12,5 Watt Prozessor bewältigt werden sollen. Systeme mit Un- terstützung der Gra󰅮ikkarten-Programmierung werden in Unterkapitel 2.3.5 vorgestellt. Um die Rechenleistung zu erhöhen (z.B. um komplexe Erkennungsalgorithmen durchführen zu können), können neben Gra󰅮ikprozessoren auch benutzerprogrammierbare, integrierte Schalt- kreise (“Field Programmable Gate Array”, kurz FPGAs) verwendet werden. Gra󰅮ikprozessoren (GPU) können dort ef󰅮izient angewendetwerden,wo (neben anderenBedingungen) Berechnun- gen stark parallelisiert werden können. Für die Implementierung der Algorithmen kann CUDA (Technologiewodurch Programmteile durch den Gra󰅮ikprozessor abgearbeitet werden können) von der Fa. Nvidia verwendet werden [Nvidia 08]. Als Alternative bietet sich OpenCL an, eine 2Low-Power Image Recognition Challenge (LPIRC), erstmals 2015 abgehalten - http://www.lpirc.net 28 Schnittstelle für uneinheitliche Parallelrechner, die neben Gra󰅮ikprozessoren auch digitale Si- gnalprozessoren ansprechen kann. Einige OpenCV-Algorithmen sind bereits in OpenCL imple- mentiert. Auch bei CUDA werden angepasste OpenCV-Bibliotheken zur Verfügung gestellt. Bei den SoC-Entwicklungsumgebungen ist vor allem das “Nvidia Jetson TK1 DevKit” zu nennen, das aus einem Tegra K1-SoC mit 192 (CUDA-fähigen) Kernen sowie einer 4-Plus-1 Quad-Core ARM Cortex-A15 CPU besteht (Leistungsaufnahme unter 10 Watt) [NVIDIA Corporation 16]. Bei di- versen Benchmark-Tests mit “State-of-the-Art”-Hardware konnten Berechnungen auf der GPU 10 bis 27 mal schneller durchgeführt werden [Rajan 14]. Bei den FPGAs werden Schaltungsstrukturen mittels Hardware-Beschreibungssprachen (Hard- ware Description Language) erstellt und nachfolgend als Kon󰅮iguration in den Baustein übertra- gen. Dadurch werden bestimmte Schalterstellungen aktiviert bzw. deaktiviert, was in Folge eine konkret implementierte digitale Schaltung ergibt. Bei den eingebetteten Systemen gibt esWerk- zeuge, die eine Konstruktion auf Funktionsblockebene anbieten, z.B. Xilinx EDK (Embedded De- velopment Kit). Funktionsblöcke,wie FIFOs, Prozessoren, serielle Schnittstellen, Ethernet-MAC- Layer, RAM-Controller, Parallel-IO etc., werden vomHersteller zur Verfügung gestellt. Unter den FPGA-SoC-Systemen ist die “Parallella-16 Embedded Platform”mit 2 CPUs und 16 FPGA-Kernen (Leistungsaufnahme unter 5 Watt) von der Firma Adapteva nennenswert. 2.4 Vergleich unterschiedlicher Hardwareplattformen Die in diesem Kapitel vorgestellten Plattformen werden in Tabelle 2.1 gegenübergestellt. Die Rechenleistung wird hierbei in Relation zur Leistungsaufnahme verglichen, um auch im Hin- blick auf einen autonomen Betriebmit alternativer Stromversorgung eine Abschätzungmachen zu können. Obwohl die CPU in einem System nicht alleine für die Leistungsaufnahme verant- wortlich ist, kann diese üblicherweise 50-60% der Leistung beanspruchen. Für den Vergleich diverser Systeme bzw. CPUs kann die Kennzahl “Leistung per Watt” (Performance per Watt - PPW) herangezogen werden [Huppler 13]. Jedoch sind solche Vergleiche alleine nicht aussage- kräftig, da auch die Prozessorarchitektur berücksichtigt werden muss [Roberts-Hoffman 09]. Generell wird bei hohem Rechenbedarf bei möglichst wenig Stromverbrauch die Verwendung der CMP-Technologie (Mehr-Kern-Prozessoren) [Barroso 05] empfohlen, wie es beispielswei- se beim Raspberry Pi 2 Model B (erhältlich seit Februar 2015) der Fall ist. Für den Vergleich 29 verschiedener Systeme kann auch die “Embedded Microprocessor Benchmark Consortium”- (EEMBC) Datenbank genutzt werden [EEMBC 16] [Poovey 09]. Hier sind allerdings nicht alle Systeme erfasst (Stand 27.02.2016). 30 S y s te m K a m e ra a N e tz w e r k A u d io b B e tr ie b s - sy s te m C V B ib li o th e k P ro z e s s o r A n z a h l K e r n e L e is tu n g s - a u fn a h m e P P W c C o re M a r k d K o s te n L e a n X ca m + + - / - L in u x L e a n C V A D S P B F -5 3 7 1 2 ,5 W 2 1 3 - 3 5 1 € E lp h e l 3 5 3 + + - / - v m tl .L in u x - A X IS E T R A X F S 1 2 ,4 - 5 ,8 W 5 9 - 7 8 9 € C M U ca m 5 + - - / - n / a v o rd e 󰅮i n ie rt N X P L P C 4 3 3 0 2 0 ,7 W - - 5 8 € A rd u in o M e g a 2 5 6 0 - / + - / + - / - n / a - A T m e g a 2 5 6 0 1 0 ,2 W 8 0 0 .5 3 2 0 € R a sp b e rr y P i - / + - / + - / + L in u x O p e n C V A R M 1 1 7 6 JZ F -S 1 1 ,5 W 5 6 5 1 .8 6 2 9 € R a sp b e rr y P i 2 (B ) - / + + + / + L in u x O p e n C V A R M C o rt e x- A 7 4 4 W 4 1 7 e - 4 2 € B e a g le B o n e - / + + - / - L in u x O p e n C V A R M C o rt e x- A 8 1 1 ,5 - 2 ,5 W 3 8 4 2 .4 2 8 7 € B e a g le B o n e B la ck - / + + - / - L in u x O p e n C V A R M C o rt e x- A 8 1 1 ,0 5 - 2 ,3 W 6 9 4 - 4 7 € T a b e ll e 2 .1 : V e rg le ic h d e r K o m p le tt sy st e m e b zw .E n tw ic k lu n g su m g e b u n g e n a Im S y st e m b zw .e rw e it e rb a r b A u d io a u fn a h m e / W ie d e rg a b e c M IP S / A ri th m e ti sc h e s M it te l zw is ch e n M in .u n d M a x .d e s L e is tu n g sv e rb ra u ch s [W ] d E E M B C C o re M a rk p e r M H z e A n g a b e n u r fü r e in e n K e rn ,b e i m e h re re n K e rn e n is t d a s A m d a h ls ch e G e se tz zu b e a ch te n 31 2.5 Sensorik Alle Komponenten mit denen bestimmte physikalische Eigenschaften einer Umgebung (z.B. op- tisch durch den CCD/CMOS-Sensor oder durch die Messung des Schallwechseldrucks durch ein Mikrofon) qualitativ oder als Messgröße quantitativ erfasst werden können, können als Senso- ren bezeichnet werden. Diemeisten Hardware-Plattformen können üblicherweisemit verschie- denen Sensoren bzw. Komponenten (Shields/Capes) erweitert werden. Die hier vorgestellten Komponenten sind für die Arbeit von besonderem Interesse. 2.5.1 Video Für Videoaufnahmen gibt es neben Modulen, die speziell für das entsprechende System ent- wickelt worden sind, auch die Möglichkeit eine USB-Kamera zu verwenden (SoC-Lösungen mit USB-Anschluss). Bei beiden Varianten werden üblicherweise CMOS-Sensoren, zumeist von der Firma OmniVision, bis ca. 5 Megapixel verwendet. Die Videoaufnahme wird meist bis zu einer Full-HD-Au󰅮lösung (1920 x 1080 Pixel) unterstützt. Bei Arduino-Systemen gibt es neben der CMUcam, die bereits in diesem Kapitel vorgestellt wur- de, auch noch Kamera-Module des Herstellers ArduCAM [ard 16]. Diese können sowohl aus einer als auch mehreren Autofokus-Kameras (OmniVision CMOS-Sensoren zw. 0,3 und 5 Me- gapixel) bestehen. ArduCAM-Module sichern bei Arduino-Systemen die Daten über den SPI- Bus direkt auf der SD-Karte. Um die Daten auszuwerten, ist die Rechenleistung eines Arduino Mikrokontroller-Boards nicht ausreichend. Für Raspberry Pi gibt es ein of󰅮izielles “Raspberry Pi Camera Module3”, das ebenfalls auf einem 5Megapixel OmniVision CMOS-Sensor (OV5647) basiert [Hughes 13]. Die Kamera besitzt einen 󰅮ixen Fokusmit einer Brennweite von3,6mm(entspricht 8mmbei Kleinformat) undunterstützt Hardware-beschleunigte Aufnahmen im H.264-Codec. Für BeagleBone bzw. BeagleBone Black ist ebenfalls ein Kamera-Cape vorhanden. Dieses verwendet einen 3,1 Megapixel CMOS-Sensor der Firma Aptina [CircuitCo 16]. Die Verwendung einer USB-Kamera (beispielsweise C920 von der Fa. Logitech) ist mit allen Sys- temen, die einen USB-Anschluss besitzen (alle Raspberry Pi bzw. BeagleBone-Systeme)möglich. 3Siehe FAQs: https://www.raspberrypi.org/help/faqs/ 32 Die Vorteile liegen darin, dass die Stromaufnahmehier laut USB 2.0 Protokoll 500mAnicht über- steigen darf [Compaq 00] und diese neben Full-HD Video- bzw. Fotoaufnahmefunktionen, wie z.B. Autofokus, auch Hardware-Codierung (H.264 oder MJPEG) und Audioaufnahmefunktionen bieten (sofern ein Mikrofon verbaut ist). 2.5.2 Audio Wie bei Videoaufnahmen kann auch bei Audioaufnahmen auf eine Vielzahl von Lösungen zuge- griffenwerden. Bei Arduino-SystemenkanndasAudio-Shield, das üblicherweise nur für dieWie- dergabe entwickeltwurde, auch für Aufnahmen verwendetwerden [Adafruit 15a] [WaveRP 16]. Weiters kann eine vereinfachte Aufnahme über die analogen Eingänge des Arduino erreicht werden [Patterson 15]. Bei den Linux-basierenden SoC-Systemen kann beispielsweise ein USB- Mikrofon bzw. eine USB-Soundkarte [g7smy.co.uk 13] oder eine speziell dafür entwickelte Erweiterung verwendet werden. Hier gibt es zum Beispiel bei BeagleBone das Audio-Cape [CircuitCo 14] bzw. bei Raspberry Pi die “Wolfson Audio Card” [Wol 14]. Zumindest eine Ein- kanalaufnahmemit einer Sample-Rate bismindestens 19 KHz ist mit allen Lösungen erreichbar. 2.5.3 Distanz Generell können Sensoren, die auf dem Prinzip der Laufzeitmessung oder Triangulation basie- ren, für Distanzmessungen verwendet werden. Bei der Laufzeitmessung wird davon ausgegan- gen, dass sich elektromagnetische und akustische Wellen mit bekannter Geschwindigkeit aus- breiten. Wenn ein Signal von einemMessobjekt re󰅮lektiert wird, kann aufgrund der Laufzeit die Entfernung zwischen zwei Punkten bestimmt werden. Beispielsweise gibt es Ultraschallsenso- ren, die auf diesem Prinzip basieren. Diese sind relativ günstig und können mit den meisten Entwicklungsumgebungen verwendet werden (beispielsweise HC-SR-04 [elecfreaks.com 15]). Jedoch liegt die maximal zuverlässig messbare Distanz bei ca. sechs Metern. Für Anwendungen mit größerer Distanz zumMessobjekt kann auf Laufzeitmessung mittels Laser oder Lasertrian- gulation zurückgegriffenwerden. Hier liegt derMessbereich zwischen einemMeter und einigen Kilometern. Die Kosten solcher Sensoren (im Vergleich zu Ultraschallsensoren) sind jedoch um Faktor 20-25 höher. Beispielsweise kostet der “LIDAR-Lite v2”-Lasersensor ca. 105€ und soll für Entfernungen bis 40 Metern genutzt werden können [Pul 15]. Die Verwendung dieser Sensoren 33 ist ebenso mit allen Hardware-Plattformen, beispielsweise über den I2C-Bus, möglich. 2.5.4 Bewegung Bewegung kann aktiv mit elektromagnetischen Wellen, Ultraschall oder anhand von Infrarot- strahlung der Umgebung erkannt werden. Am häu󰅮igsten werden passive Sensoren verwendet, die Infrarotstrahlung registrieren (PIR-Sensoren). Hierbei wird die Wärmestrahlung vom Ob- jekt (z.B. Mensch, Tier, Kraftfahrzeug) im mittleren Infrarotbereich gemessen. Der Erfassungs- bereich von einem PIR-Sensor liegt je nach Typ bei ca. 40Metern bei einem Einstrahlwinkel von 180°. PIR-Sensoren sind preiswert und können in allen Entwicklungsumgebungen ausgelesen werden. Zumeist geschieht dies durch das GPIO. Üblicherweise können sowohl Einschaltdauer als auch Umgebungshelligkeit (Hell-Dunkel-Grenze) durch zwei Widerstände (Potentiometer) festgelegt werden [Par 14]. 2.5.5 Helligkeit Fotodetektoren (Fotowiderstände) bzw. Lichtsensorenwandeln Licht unter Benutzung des foto- elektrischen Effekts in Spannung, Stromoder Frequenz um,welche dannweiterverarbeitet wer- den kann. Ein einfacher Fotowiderstand ändert je nach Lichteinstrahlung seinenWert. Die durch den Effekt entstandene Spannung bzw. Stromveränderung kann beispielsweise durch analoge Eingänge des Arduinos bzw. BeagleBones registriertwerden. Bei Entwicklungsumgebungen, die über keine analogen Eingänge verfügen, kann auch ein “Licht zu Frequenz-Umwandler” (z.B. TSL235 [Tex 94]) verwendet werden, da hier die Frequenzänderung durch die digitalen GPIO- Ports abgefragt werden kann. 2.5.6 Echtzeituhr Da die meisten Entwicklungsumgebungen über keine Echtzeituhr, sondern nur über logische Uhren verfügen, ist ein Modul notwendig, das als physikalischer Zeitgeber fungiert. Solche Mo- dule ermöglichenes auch, dieUhrzeit beimAusschaltendes Systemszuerhaltenundkönnenbei- spielsweise über das I2C-Protokoll angesprochen werden. Üblicherweise kann neben der Uhr- zeit auch das Datum gesetzt sowie ausgelesenwerden (siehe Datenblatt vomMI-DS1307-Modul 34 [Max 15]). Zur Synchronisation der Uhr im System kann bei Verfügbarkeit einer Netzwerk- Verbindung das “Network Time Protocol” (NTP) verwendet werden. 2.6 Entwicklungsumgebungen und Bibliotheken Analog zur Hardware, gibt es auch bei derWahl des Betriebssystems, der Programmiersprache, der Programmbibliothekenmit Algorithmen für Bildverarbeitung undmaschinelles Sehen oder dermöglichen Entwicklungsumgebungen eine Vielzahl an Auswahlmöglichkeiten, die in diesem Unterkapitel vorgestellt werden. Neben den populären bzw. meistgenutzten Bibliotheken, wie z.B. OpenCV bzw. deren Abwand- lungen und Wrapper (JavaCV, SimpleCV etc.), werden hier auch weniger bekannte Bibliothe- ken (FastCV, CCV) behandelt. Neben den wichtigsten Kriterien, wie Benutzbarkeit, Funktio- nalität und Zuverlässigkeit, wird vor allem die Lauffähigkeit auf “Embedded Systems” sowie die für die Softwareentwicklung wichtigen Aspekte, Dokumentation der API oder Debugging- Möglichkeiten, evaluiert.Wie ausderUmfragederUBMTechElectronics “EmbeddedMarket Stu- dy” aus den Jahren 2010 bis 2014 unverändert herausgeht, ist gerade die Nutzung bzw. Einfach- heit der Debugging-Möglichkeiten bei den eingebetteten Systemen der Punkt mit dem größten Verbesserungspotential. Weiters geht aus der gleichen Studie hervor, dass die Verfügbarkeit der Softwareentwicklungswerkzeuge noch vor der Leistungsfähigkeit des Prozessors maßgebend für dessen Auswahl ist [UBM Tech 14]. Für eine umfangreiche Softwarebewertung können bei- spielsweise Unterscheidbarkeitskriterien nach den ISO/IEC 9126-1 bzw. ISO/IEC 25010:2011 Standards (siehe Software-Engineering-basierendeCheckliste [Jackson 11]) herangezogenwer- den. Die in diesem Kapitel vorgestellten Lösungen sowie deren Vor- und Nachteile wurden an- hand einer Literaturrecherche ermittelt. 2.6.1 Bibliotheken für maschinelles Sehen Bibliotheken fürmaschinelles Sehen können je nach Anwendungsgebiet grob in drei Kategorien eingeteilt werden: • Bibliotheken, die hauptsächlich für Algorithmenentwicklung bzw. numerische Berech- nungen verwendet werden (beispielsweise MATLAB) bzw. für robusten, nahezu system- 35 unabhängigen Produktiveinsatz geeignet sind (beispielsweise OpenCV). • Bibliotheken, die auf Performance in einer bestimmten Umgebung optimiert sind (bei- spielsweise FastCV). • Bibliotheken, die aus mehreren solchen bestehen und nicht ausschließlich für maschinel- les Sehen verwendet werden (beispielsweise liegt der Fokus bei Processing und open- Frameworks auf audiovisueller Kunst). OpenCV Die heutzutage bedeutendste Bibliothek für maschinelles Sehen ist OpenCV (CV - kurz für Com- puter Vision) [Bradski 00]. Sie wurde 1999 auf Initiative von “Intel Research” ins Leben ge- rufen. Als Hauptziel wurde die Entwicklung einer Bibliothek, die nicht nur die neuesten CV- Algorithmen, sondern auch einen optimierten Quellcode zur Verfügung stellt, de󰅮iniert. Wei- tere Ziele waren die Wissensvermittlung bzw. Bereitstellung einer Infrastruktur, um eine Wei- terverbreitung und leichtere Lesbarkeit von neuen Algorithmen bzw. darauf basierenden Ap- plikationen zu ermöglichen. OpenCV ist plattformunabhängig auf Open-Source-Basis verfügbar. Weiters können Applikationen, die auf Basis von OpenCV verwirklicht wurden, auch kosten- p󰅮lichtig vertrieben werden. Die größten Stärken von OpenCV liegen in der Geschwindigkeit und der großen Menge an Algorithmen, die relativ schnell aus neuesten Forschungsergebnis- sen in die Bibliothek aufgenommen werden. OpenCV ist in C++ geschrieben und auch die Basis- Programmierschnittstelle ist in C++ gehalten, allerdings sind in der Version 2.5 Wrapper, sowie Online-Dokumentationen für Python, Java sowie MATLAB verfügbar. Weitere Wrapper für Pro- grammiersprachenwie C#, Perl, Ch undRuby sindmittlerweile auch verfügbar, umdie Plattform einer breiteren Zielgruppe zugänglich zu machen. Um eine bessere Performance zu erreichen, werdenmanche Algorithmen seit der Version 2.4.3 auch in OpenCL (siehe Kapitel 2.3.5) zur Ver- fügung gestellt. JavaCV JavaCV benutzt sowohl OpenCV als auch Wrapper von anderen Bildverarbeitungsbibliotheken, wie beispielsweise FFMPEG [Bellard 12] oder OpenKinect [Blake 11]. Diese auf Java basierende Bibliothek kann somit als Basis für Medienverarbeitung bzw. maschinelles Sehen in Java ver- 36 wendet werden. Von Seiten der Open-Source-Community wird jedoch bemängelt, dass die Do- kumentation nicht vollständig ist bzw. nur wenige Implementierungsbeispiele vorhanden sind [Audet 11]. FastCV Die FastCV-Bibliothek stellt für mobile Geräte eine optimierte Bibliothek für maschinelles Se- hen zur Verfügung. Es werden auf ARM-Prozessoren basierende Systeme ef󰅮izient unterstützt, jedoch ist die Bibliothek besonders für den Qualcomm Snapdragon Prozessor optimiert. Somit können komplexe Algorithmen für Gestenerkennung, Gesichtserkennung oder Texterkennung durch Verwendung der Hardwarebeschleunigung schneller ausgeführt werden [Qua 14]. SimpleCV SimpleCV ist ebenfalls eine Open-Source-Bibliothek fürmaschinelles Sehen, die auf OpenCV au󰅮- baut und für die Programmiersprache Python zur Verfügung steht [Demaagd 12]. Diese Biblio- thekunterstützt die allgemeinenAufgabenderBildaquisition, Bildbearbeitung sowieMerkmals- erkennung und kann somit auch für die Erstellung der “Proof-of-Concept”-Lösung verwendet werden. Als Anwendungsgebiet ist schnelles Prototyping beschrieben, das selbst für Einsteiger geeignet ist. C-based Computer Vision Library Als relativ neueAlternative zuOpenCV ist CCV zu nennen. Hierbei handelt es sich umeine “Appli- kationsgesteuerte” Bibliothek, die nur wenige, vom Anwendungsgebiet abhängige, moderne Al- gorithmen beinhaltet [Liu 10]. Beispielsweise ist hiermit die Klassi󰅮izierung mittels neuronalen Netzwerken oder auchObjekterkennungmit unterschiedlich trainierbaren, teilbasiertenModel- lenmöglich [Felzenszwalb 10]. Die Bibliothek kann auf denmeistenUnix-basierenden Systemen betrieben werden und ist beispielsweise für das Raspberry Pi vorkompiliert verfügbar. 37 MATLAB Matlab ist eine Entwicklungsumgebung, die auf mathematischen Methoden basiert [Moler 80]. Diese wird primär für numerische Berechnungen mithilfe von Matrizen sowie Entwicklungen neuer Algorithmen verwendet. Für die Verwendung im Bereich des maschinellen Sehens steht das “Computer Vision System Toolbox” zur Verfügung [Inc. 16]. Die Hauptmerkmale in diesem Bereich sind unter anderem Merkmalerkennung, Extraktion und Abgleich, Objekterkennung (mit Viola-Jones [Viola 01] und trainiertenDetektoren), ObjektverfolgungundBewegungsschät- zung. Für die Verwendung im Bereich der eingebetteten Systeme bietet Matlab Unterstützung für das Raspberry Pi4. openFrameworks openFrameworks ist nicht ausschließlich für maschinelles Sehen gedacht, sondern vor allem als eine Ansammlung verschiedener Bibliotheken (Frameworks) für einen breiteren Gebrauch (in C bzw. C++). Unter den verwendeten Bibliotheken sind beispielsweise OpenGL, PortAudio, Quicktime und OpenCV zu nennen. Die Portierbarkeit spielte bei der Erstellung des openFrame- works eine sehr wichtige Rolle. Somit ist eine Verwendung mit den meisten Betriebssystemen und Software-Entwicklungsumgebungen, beispielsweiseWindows, OSX, Linux, iOS oder Andro- id, möglich. Auch eine Verwendung mit Raspberry Pi, BeagleBone sowie ähnlichen auf ARM- Prozessoren basierenden Systemen ist möglich. Die von openFrameworks intendierte Zielgrup- pe ist imBereich kreativer, künstlerischerDarstellungmit Verwendung eines Low-Level-Zugriffs auf die in Medien enthaltenen Daten tätig [Lieberman 05]. Processing Auch Processing wird hauptsächlich im Bereich der audiovisuellen Kunst verwendet. Anders als bei openFrameworks wird hier jedoch keine Low-Level Programmiersprache (z.B. C/C++) sondern Java bzw. JavaScript verwendet. Auch Processing ist auf ARM-Prozessoren basierenden Systemen lauffähig. Seit der Version 3.0 ist der Hardware-Zugriff auf die GPIO-Schnittstelle des Raspberry Pi möglich [Adafruit 15b]. 4Siehe: http://de.mathworks.com/hardware-support/raspberry-pi-simulink.html. Nur für von MATLAB in C- übersetzbare Funktionen möglich. 38 2.6.2 Zusammenfassung Eine kurze Zusammenfassung der Bibliotheken sowieMöglichkeiten zu derenVerwendung ist in Tabelle 2.2 angeführt. Für weiterführende Literatur zu openFrameworks und Processing (auch in Verwendung mit eingebetteten Systemen) ist das Buch von J. Noble, “Programming Interac- tivity” [Noble 09], zu empfehlen. Bibliothek Sprache Bereich Besonderheit Verfügbarkeit OpenCV C, C+, Java, Python Appl.-Entw. Breite Anwendbarkeit Open Source JavaCV Java Appl.-Entw. Hardware-Beschleunigung Open Source FastCV C, C++ Appl.-Entw. Optimiert für Snapdragon Proprietär SimpleCV Python Prototyping Einfache Bedienung Open Source CCV C, C++ Appl.-Entw. Wenige moderne Algorithmen Open Source MATLAB MATLAB Forschung Breite Anwendbarkeit Proprietär openFrameworks C, C++ AV-Kunst Portierbar Open Source Processing Java AV-Kunst Einfache Bedienung Open Source Tabelle 2.2: Vergleich der Bibliotheken sowie deren Anwendung 39 40 Kapitel 3 Ansatz und Implementierung In diesem Kapitel werden die Anforderungen an das zu entwickelnde System detailliert auf- geführt und diskutiert sowie basierend auf einer Vorevaluierung die Auswahl der Hardware- Plattformen und der verwendeten Software (bzw. Softwarebibliotheken) und Hardware durch- geführt. Neben der Auswahl der Komponenten werden die Architektur der Hardware bzw. Soft- ware sowie die grundlegenden Prozessabläufe de󰅮iniert. Wie bereits in Kapitel 2 ersichtlich, ist hier eine große Anzahl an Auswahlmöglichkeiten vorhanden. Weiters wird eine Beschreibungs- sprache de󰅮iniert, die zur Kon󰅮iguration des Systems dienen soll. 3.1 Anforderungen Die Mindestanforderungen wurden bereits in Kapitel 1 vorgestellt. Durch die Evaluierung der vorhandenen Systeme bzw. der zur Verfügung stehenden Hardware-Plattformen, werden hier endgültige Anforderungen an das System bzw. an die “Proof-of-Concept”-Lösung festgelegt. Ne- ben den Anforderungen, die für das Gesamtsystem gelten (Tabelle 3.1), werden auch spezielle Anforderungen an bestimmte Sensoren bzw. an die Software (Tabelle 3.2) und den Stromver- brauch de󰅮iniert. Es ist erwünscht, den Betrieb des Systems autonom, ohne externe Stromversorgung durchfüh- ren zu können. Die Energie soll durch eine kleine Photovoltaik-Anlage zur Verfügung gestellt werden können. Beispielsweise produziert eine 25 x 25 cm große Anlage typischerweise ca. 9 41 Watt (Spitzenwert)1. Es soll sichergestellt werden, dass die Benutzung (Aufnahme) sowie das Au󰅮laden der Batterie gleichzeitig durchgeführt werden kann. Somit soll die maximale Leis- tungsaufnahme des Systems selbst (exkl. Batterieladen) bei ca. 5Watt liegen (siehe Tabelle 3.4). Anforderungen - Gesamtprojekt Verbindlichkeit Umsetzung Aufnahme von verschiedenen, de󰅮inierten Sensordaten P󰅮licht Audio-, Video-, Distanz-, Bewegungs- und Helligkeitsdaten, siehe Tabelle 3.3 Datenübertragung über TCP/IP - Ethernet oder WLAN-Schnittstelle P󰅮licht USB-WLAN-Stick, On-Board-Netzwerkkarte, Netzwerkkarten-Zusatzplatine Speicherung der Daten auf einem auswechselbaren, externen Datenträger P󰅮licht USB-Festplatte, eingebaute SD-Karte Mustererkennung (Objekterkennung) mit gängigen Bibliotheken zummaschinellen Sehen P󰅮licht z.B. OpenCV Versetzen in Sparmodus mittels Software P󰅮licht CPU-Drosselung System soll kompakte Maße besitzen und preisgünstig sein P󰅮licht - Möglichkeit einer Mobilfunk-basierenden Datenübertragung Optional GPRS/3G Modul Das zu erstellende Software-Framework soll leicht erweiterbar sein, vor allem im Hinblick auf die Verwendung neuer Sensoren und Erstellung neuer Erkennungsalgorithmen. P󰅮licht Wenn möglich, Verwendung von Objektorientierter Software Architektur mit zur Verfügung gestellten Interfaces Tabelle 3.1: Anforderungen - Gesamtsystem 1Beispielsweise “Voltaic 9 Watt Solar Panel” - http://www.voltaicsystems.com/9-watt-panel 42 Anforderungen - Software Verbindlichkeit Umsetzung Multithreading-Unterstützung P󰅮licht Linux: POSIX-Threads, C++11 Multithreading Audio- und Videoaufnahme in Echtzeit (Synchronizität soll gegeben sein) P󰅮licht - Videoverarbeitung mittels gängiger Bibliotheken zummaschinellen Sehen P󰅮licht OpenCV, FastCV Erstellung eines Queueing-Mechanismus P󰅮licht - Einstellbare Aufnahmezeiten (Start, Stopp) sowie einstellbare Intervalle der Sensoren (bei Videoaufnahme zusätzlich die Au󰅮lösung) P󰅮licht - Einfache Kon󰅮iguration des Systems P󰅮licht XML-Kon󰅮igurationsdatei Autonome Aufnahme bei der Auslösung durch einen Trigger-Mechanismus (z.B. durch den Bewegungsmelder) P󰅮licht - Aufnahme mehrerer Sensoren gleichzeitig (z.B Audio, Video, Bewegung, Helligkeit) P󰅮licht Multithreading Unterschiedliche Arten von Trigger-Verfahren: Zeitliche Trigger, Sensor-basierte Trigger (z.B. Helligkeit > Threshold) und Algorithmus als Trigger (z.B. Aufnahme, wenn ein Objekt erkannt wird) P󰅮licht - Hardware soll in Ruhe- bzw. Sparmodus versetzt werden können P󰅮licht Linux, CPU-Drosselung Entfernte Kon󰅮iguration Optional Webservice Nachrichtenversand bei Auftreten eines Ereignisses Optional Webservice (Push-API) Leicht erweiterbares Software-Framework P󰅮licht - Tabelle 3.2: Anforderungen - Software 43 Anforderungen - Sensoren Verbindlichkeit Umsetzung Einkanal-Audioaufnahme P󰅮licht USB-Mikrofon + Audio-Eingang, USB-Webkamera mit Mikrofon Videoaufnahme in Echtzeit P󰅮licht USB-Kamera, Kamera-Module - Evaluierung der vorgestellten Systeme notwendig Distanzmessung P󰅮licht Ultraschall- oder LIDAR-Sensor Bewegungserkennung P󰅮licht Infrarot-Bewegungsmelder (Digital) Helligkeitsmessung P󰅮licht Helligkeitssensor 5V bzw. Fotowiderstand (Analog) Video: Mindestau󰅮lösung des Videosensors 1280 x 720 Pixel P󰅮licht USB-Kamera bzw. Kamera-Module Mindestbildwiederholrate bei Aufnahme 10 FPS P󰅮licht - Weitwinkel-Optik (Bildwinkel im Bereich zwischen 75° und 120°) P󰅮licht Typischerweise werden Kameras mit einer solchen Optik versehen Autofokus Optional - Tabelle 3.3: Anforderungen - Sensoren Die durch Sensoren (siehe Tabelle 3.3) generierten Daten können jeweils aufgenommen (Da- tenträger) bzw. für das Starten einer Aufnahme verwendet werden. Ob ein Sensor nur für die Aufnahme oder als Trigger verwendet werden kann, wurde bereits in Kapitel 1 und Tabelle 1.1 festgelegt. Anforderungen - Stromaufnahme Verbindlichkeit Umsetzung Maximale Leistungsaufnahme (inkl. aller Komponenten, sowie Batterieladen) soll 9 Watt nicht überschreiten P󰅮licht - Leistungsaufnahme von 0,12 kWh pro Tag soll nicht überschritten werden (5W * 24h) P󰅮licht - Tabelle 3.4: Anforderungen - Stromaufnahme 44 3.2 Vorevaluierung Für die Entwicklung des “Proof-of-Concept”-Systems wurde im Vorfeld eine Selektion der Hardware-Plattformen durchgeführt, um eine engere Auswahl für die Vorevaluierung zu er- halten. Hierbei wurden ein Mikrokontroller-basierendes System (Arduino 2560), ein Ein-Kern- SoC-System (BeagleBone bzw. BeagleBone Black) sowie ein Mehr-Kern-SoC-System (Raspber- ry Pi rev. A und 2 B) ausgewählt. Andere leistungsfähigere Systeme aus dem Mehr-Kern-SoC- Bereich, wie beispielsweise “Nvidia Jetson TK1”, wurden aufgrund des hohen Preises bzw. zu hohen Stromverbrauchs nicht weiter berücksichtigt. Die Auswahlkriterien für die Selektion und das weitere Vorgehen im Zuge der Vorevaluierung sind wie folgt festgelegt (Priorität absteigend): • Stromaufnahme des Gesamtsystems, • Erweiterungsfähigkeit des Systems, • Leistungsfähigkeit des Systems imHinblick auf Video- und Audioaufnahme sowie auf Aus- führung von komplexen Algorithmen aus dem Bereich des maschinellen Sehens, • Verfügbarkeit der Hardware-Plattformen und Bibliotheken zur Softwareentwicklung. In der Phase der Vorevaluierung soll die detaillierte Stromaufnahme des Gesamtsystems (inkl. Sensoren) anhand der Datenblätter sowie in weiterer Folge anhand von Strom- und Spannungs- messungen ermittelt werden. 3.2.1 Stromverbrauch Der Stromverbrauch wurde anhand der Datenblätter bzw. im Falle des Fehlens der Datenblät- ter durch Literaturrecherche erhoben (siehe Tabelle 3.5). Es wurden nur die Kennzahlen für die Platinen selbst sowie für jeweils kompatible Komponenten angegeben. Bei allen anderen Kom- ponenten (z.B. für Distanz- oder Bewegungssensor) kann davon ausgegangen werden, dass der Stromverbrauch unabhängig vom verwendeten Board ist2. 2Ausgenommen bei Raspberry Pi, da keine analogen Eingänge vorhanden sind (beispielsweise für die Verwen- dung eines Foto-Widerstands zwecks Helligkeitsmessung). Hier kann zum Beispeil ein AD-Wandler oder “Licht zu Frequenz-Umwandler - TSL235” verwendet werden. Die Stromaufnahme ist jedoch unabhängig von der ausgewähl- ten Lösung im μA-Bereich und somit vernachlässigbar. 45 Komponente Arduino 2560 [W] BeagleBone Black [W] Raspberry Pi Rev. A [W] Raspberry Pi 2 B [W] System 0,13 - 0,70 1,05 - 2,30 1,50 4,00 Netzwerk (WLAN/RJ45) 0,05 - 0,60a - 1,25 - 2,50b - Videoaufnahme 0,70 - 0,70c 1,25 - 2,50d 1,25e 1,25e Gesamt 0,88 - 2,00 2,30 - 4,80 4,00 - 5,25 5,25 Tabelle 3.5: Stromverbrauch aW5100 Chipset - Arduino-Shield [WIZ 08] bUSB-Netzwerkkarte, max. 500mA cCMUcam5 [Lang 16] dUSB-Kamera, max. 500mA - inkl. Mikrofon und Videokomprimierung ePi Camera Module [pic 16] Alleine wegen des Stromverbrauchs ist das Arduino 2560 zu bevorzugen, da hier von einer ma- ximalen Leistungsaufnahme von 2 Watt auszugehen ist. Dieses hat, wie bereits in Kapitel 2.3.2 angesprochen, eine hohe Anzahl an Erweiterungsplatinen (Shields). Um die Anforderungen zu erfüllen, ist das Netzwerk-Shield für die Datenübertragung sowie die CMUcam5 [Lang 16] un- d/oder das ArduCAM-Shield [ard 16] für die Videoaufnahme bzw. Objekterkennung erforder- lich. Bei BeagleBone Black, das trotz höherer CPU-Taktfrequenz weniger Strom als das Beagle- Bone (Version 1) benötigt, ist zur Erfüllung derAnforderungenprimär eine Erweiterungsplatine (Kamera-Cape) oder eine USB-Kamera notwendig. Ähnlich können Raspberry Pi-Boards sowohl mit einer USB-Kamera als auch mit dem extra für dieses Board entwickelten Kamera-Modul (Pi Camera Module) verwendet werden. 3.2.2 Vergleich der Hardware-Plattformen Im Folgenden werden die unterschiedlichen Hardware-Plattformen in Hinsicht auf die gegebe- nen Anforderungen verglichen. Die Anforderungen lassen sich vereinzelt mit nahezu jedem die- ser Systeme umsetzen (siehe Tabelle 3.6). Mit demMikrokontroller-basierenden Arduino 2560 ist es jedoch nicht möglich, Videodaten aufzunehmen und nachträglich auszuwerten. Für die 46 Aufnahme ist die Zusatzplatine ArduCAMnotwendig, die die Daten direkt auf der SD-Karte spei- chert. Durch die sehr langsame Verarbeitungsgeschwindigkeit des Mikrokontrollers mangelt es auch an Möglichkeiten zur maschinellen Bildverarbeitung. Eine weitere Limitierung stellt die niedrige Geschwindigkeit (max. 400 kbit/sec.) des I2C-Busses dar, der für die Kommunikation zwischen demArduino und der ArduCAMdient [ard 09].Was jedochmöglich ist, ist die Verwen- dung des CMUcam-Zusatzmoduls, das bereits eine Objekterkennung durchführt (siehe Kapitel 2.3.1) und nur die Ergebnisse an das Arduino-Board liefert. Im Rahmen einer Testimplementie- rungwurde jedoch festgestellt, dass der gesamte Arbeitsspeicher des Arduino 2560 (16 kBytes) nach Verwendung der Bibliotheken für die Speicherung der Daten auf einer SD-Karte sowie ei- nes Web-Servers für die Kommunikation über das TCP/IP-Netzwerk bereits ausgereizt worden ist. Komponente Arduino 2560 BeagleBone Black Raspberry Pi A Raspberry Pi 2 B Audio + + + + Video -a + + + Bewegung + + + + Distanz + + + + Helligkeit + + + + b Tabelle 3.6: Erweiterungsmöglichkeiten aEntweder Aufnahme (ArduCAM - direkt auf der SD-Karte) oder Objekterkennung (CMUcam) möglich. bDurch Verwendung von “Licht-zu-Frequenz-Umwandler - TSL235”. Die Erweiterungsmöglichkeiten betreffend ist BeagleBone Black zu bevorzugen. Dieses hat ne- ben den GPIO-Schnittstellen und dem SPI-BUS (analog zu Raspberry Pi) auch analoge Eingänge sowie eine programmierbare Echtzeit-Einheit (Programmable Real-Time Unit - PRU), die es er- möglicht zeitkritische Anwendungen unabhängig vom Linux-Kernel laufen zu lassen. Die PRU- Einheit ist dazu gedacht, industrielle Kommunikationsprotokolle zu implementieren und kann beispielsweise für dieKommunikation zwischendemUltraschallsensorundBeagleBone genutzt werden. Wenn es um die Verarbeitungsgeschwindigkeit geht, sind zwischen BeagleBone Black und Raspberry Pi 2 B nur bei Algorithmen, die auf Mehr-Kern-Prozessoren ausgelegt sind, Un- 47 terschiede zu erwarten. Hierbei ist noch anzumerken, dass beispielsweise bei OpenCVMehrkern unterstützende Algorithmen nur vereinzelt vorhanden sind, da hier der Fokus auf Gra󰅮ikkarten- Programmierung (CUDA) liegt [Pulli 12]. Eine Testimplementierung auf diesen Systemenwurde nicht durchgeführt. 3.3 Auswahl der Hardware und Software Aus dem Ergebnis der Vorevaluierung ist ersichtlich, dass die Anforderungenmit Arduino 2560 nicht zu erfüllen sind. ImVergleich zwischenBeagleBoneBlackundRaspberryPi-Lösungenwur- de BeagleBone Black aufgrund des niedrigeren Stromverbrauchs sowie der weitaus besseren hardwarebedingten Erweiterbarkeit für die Implementierung der “Proof-of-Concept”-Lösung ausgewählt. Um BeagleBone bzw. Raspberry Pi Hardware stromsparender zu betreiben, ist es jedoch bei beiden möglich die CPU-Taktfrequenz runterzusetzen [Brodowski 13]. Bei einem Projekt mit dem Hauptfokus auf Datenauswertung, d.h. Ausführung von komple- xen Algorithmen (vorausgesetzt diese sind für Mehr-Kern-Systeme ausgelegt), und weniger auf Stromverbrauch wäre eine Raspberry Pi 2 B Lösung zu bevorzugen. Für die Regulierung des Eingangsstroms bzw. Ladevorgangs kann das BeagleBone Power-Cape verwendet werden. Weiters wird durch das Power-Cape eine komplette Abschaltung des Sys- tems sowie eine Einschaltung nach verstrichener Zeit ermöglicht. Die Schaltpläne sowie Firm- ware dafür sind frei verfügbar. Die Auswahl weiterer Komponenten wird in den folgenden Un- terkapiteln begründet. 3.3.1 Betriebssystem und Programmiersprache Generell sind alle Linux-Distributionen, die auf ARM-Prozessoren kompilierbar sind, auf den BeagleBone-Systemen lauffähig. Ausgeliefert werden die Systeme mit Ångström Linux, das spe- ziell für eingebettete Systeme entwickelt wurde. Hier wurde Debian Linux vor allem wegen einer breiteren Community-Unterstützung anstelle von Ångström Linux bevorzugt. Als Linux-Kernel wurde Linux ARM 4.2.1. mit Real-Time Sup- port ausgewählt. Real-TimeKernel habeneineniedrigeLatenzzeit,wasbeispielsweise fürAudio- aufnahmen notwendig ist. Um die volle Funktionalität der BeagleBone Black-Hardware auszu- 48 schöpfen, ist weiterhin die Verwendung von Linuxmit Unterstützung der “Device TreeOverlays” notwendig. Diese ermöglichen es, die zur Verfügung stehenden physischen Anschlüsse mit ver- schiedenen Funktionen zu überlagern. Beispielsweise ist für die Verwendung des AD-Wandlers oder der PRU-Einheit das Einspielen der entsprechenden “Device Tree”-Überlagerung notwen- dig. Dies ist bei Debian Linux möglich. Als Programmiersprache wurde C++ gewählt. Die Gründe dafür liegen unter anderem bei dem Geschwindigkeitsvorteil sowie dem geringeren Speicherverbrauch (da nur 512 MB zur Ver- fügung stehen) gegenüber interpretierten Programmiersprachen, wie beispielsweise Python [Prechelt 00]. Ein weiterer Vorteil von C bzw. C++ ist die Möglichkeit der hardwarenahen Pro- grammierung. Obwohl im Bereich der eingebetteten Systeme die Programmiersprache C gegen- über C++ bevorzugt wird, basiert dies teilweise auf Fehlannahmen, dass C++ langsamer sei und unverhältnismäßigmehr Speicherplatz benötigenwürde. Dieswird beispielsweise vonDominic Herity [Herity 98] widerlegt. 3.3.2 Video und Audio Für die Videoaufnahme wird das Kamera-Cape [CircuitCo 16] bzw. eine USB-Webkamera vom Typ Logitech C920 und für die Audioaufnahme das BeagleBone Audio-Cape sowie ebenfalls die USB-Kamera genutzt. Im Zuge der Evaluierung (Kapitel 4) werden die Ergebnisse der Aufnahme in Bezug auf Stromverbrauch, Qualität und Geschwindigkeit für die verschiedenen Kameras und Aufnahmemethoden ermittelt. 3.3.3 Echtzeituhr Als Zeitgeber wird das Modul DS1307 (bereits in Kapitel 2.5.6 vorgestellt) verwendet. Das Mo- dul kommuniziert über das I2C-Protokollmit demBeagleBone-System.Nach erfolgreicherRegis- trierung des Moduls kann die Uhrzeit direkt in der Linux-Benutzerschnittstelle mit dem Befehl “hwclock -r|w -f /dev/rtc1” gesetzt bzw. ausgelesenwerden [Max 15]. Hier ist zu beachten, dass die Betriebsspannung (Vcc) desModuls 5 Volt beträgt und der Spannungspegel für ein logisches Highmaximal 5,3 Volt (Vcc + 0,3) betragen kann. Dies kann bei BeagleBone Black zu einer Über- hitzung bzw. Zerstörung von Bauteilen führen, da ein logisches High hier max. 3,3 Volt betragen darf [Coley 13]. Um dies zu vermeiden, wird ein I2C-Bus-Pegelwandler verwendet. 49 3.3.4 Bewegung Hierwurde ein einfacherundpreisgünstigerPIR-Sensor, der überdieGPIO-EingängedesBeagle- Bone ausgelesenwerden kann, ausgewählt. Ebenfalls soll auch hier ein Pegelwandler verwendet werden, da das logische High des PIR-Sensors höher als bei BeagleBone Black ist. 3.3.5 Helligkeit Um Helligkeit zu erfassen, wird der eingebaute Analog-Digitalwandler des BeagleBone Black und ein Fotowiderstand verwendet werden. Es ist zu beachten, dass Fotowiderstände keine ka- librierten Belichtungsmesser sind, sondern nur relative Lichtänderungen messen können. Um die Lichtintensität in sinnvollen Maßeinheiten zu erhalten, ist eine Lookup-Tabelle erforderlich. 3.3.6 Distanz Für die Distanzmessung wurde vor allem aus Kostengründen der HC-SR-04 Ultraschallsensor (statt einemLasersensor) ausgewählt [elecfreaks.com 15]. Dieser funktioniert nachdemPrinzip der Laufzeitmessungundbenötigt somit ein exaktesTrigger-Signal sowie eineEchtzeit-Messung der Laufzeitverzögerung. Diese Aufgabenstellung kann über die programmierbare Echtzeit- Einheit (Programmable Real-Time Unit - PRU) der BeagleBone-Entwicklungsumgebung zuver- lässig gelöst werden. 3.3.7 Auswahl der Programmierbibliotheken Wie bereits in Unterkapitel 3.3.1 angegeben, wurden als Basis für das System C++ sowie ein Linux-Betriebssystem ausgewählt. Somit bietet sich an, die meistverbreitete Bibliothek für maschinelles Sehen, nämlich OpenCV, zu verwenden. Für die Videoaufnahme kann direkt die OpenCV-Klasse “VideoCapture” verwendetwerden.Weiters ist der Zugriff auf Video- undAudio- Datenquellen (Aufnahmegeräte) auf Linux-Systemen über die Video4Linux2-Bibliothek mög- lich. Für die Audioaufnahme kann sowohl die ALSA-Audio-Bibliothek (Low-Level) als auch eine daran au󰅮bauende (High-Level) Bibliothek, wie beispielsweise PortAudio, verwendet werden. Neben den unten vorgestellten Programmierbibliotheken soll für gleichzeitig statt󰅮indende Auf- gaben, beispielsweise gleichzeitige Audio- und Videoaufnahme, die C++11 Thread-Erweiterung 50 verwendetwerden. Umdie XML-Kon󰅮igurationsdatei auszulesen bzw. auszuwerten, wird die “li- bxml++”-Bibliothek verwendet, die eine XPath-Unterstützung bietet und somit die Möglichkeit besitzt, nur bekannte Teile des XML-Dokuments zu adressieren und auszuwerten. OpenCV OpenCV wird vor allem wegen der breiten Unterstützung, Vielseitigkeit und der breiten Erwei- terungsmöglichkeiten ausgewählt. Bei anderen, in Kapitel 2.6.1 angeführten (C bzw. C++ basie- renden) Bibliotheken fürmaschinelles Sehen, werden die fehlendenDokumentationen bzw. feh- lendenBeispiel-Umsetzungen erwähnt (z.B. JavaCV). Für dasAusscheidender FastCV-Bibliothek (Optimierung für ARM-Prozessoren) ist vor allem die beschränkte Anzahl an Algorithmen ver- antwortlich. Die Verwendung von openFrameworks (mit OpenCV)wurde aus demGrund ausge- schlossen, dass nur wenige Bibliotheken aus dem Gesamt-Framework tatsächlich Verwendung 󰅮inden könnten und die nicht verwendeten den beschränkten Speicherplatz verbrauchen wür- den (z.B. OpenGL, GLEW,QuickTime, FreeTime). Bei derVerwendungderOpenCV-Bibliothek soll es durch die “Proof-of-Concept”-Lösung möglich sein, aufgenommene Videos bzw. Einzelbilder direkt im OpenCV-Format (cv::Mat) zu speichern und in weiterer Folge zu manipulieren. Unter anderem könnte die Optimierung der Aufnahmegeschwindigkeit des OpenCV-Framegrabbers bzw. Video-Grabbers notwendig sein, um die Anforderungen zu erfüllen. PortAudio Bei der Verwendung der Audio-Bibliothek wurde PortAudio ausgewählt. Dies ist vor allem der Verständlichkeit und Einfachheit der Programmierschnittstelle zu verdanken, da diese eine schnelle und einfache Umsetzung der Aufnahme und Speicherung der Daten ermöglicht. Wei- ters ist mit der Auswahl der PortAudio-Bibliothek eine einfache Portierung (beispielsweise auf ein Windows-Betriebssystem) möglich. Wie aus der Arbeit von Topliss et al. [Topliss 14] her- vorgeht, ist die Latenz-Zeit bei der Audioaufnahme sowohl mit dem USB-Mikrofon als auch dem BeagleBone Audio-Cape sehr niedrig und ermöglicht somit die Verwendung des BeagleBone als digitales Musikinstrument. 51 3.4 Hardwarearchitektur Die Hardwarearchitektur wurde auf Basis von BeagleBone Black erstellt. Die in den Unterka- piteln 3.3.2 bis 3.3.6 ausgewählten Sensoren können über verschiedene BeagleBone-Einheiten angesprochen werden. BeagleBone / BeagleBone Black Helligkeitssensor Fotowiderstand Distanzsensor HC-SR-04 PRU-Einheit GPIOAD-Wandler USB Host / Cape Bewegungssensor PIR-Modul (IR) Video- / Audiosensor Kamera-Cape / USB I2C-Bus Echtzeituhr DS 1307 Abbildung 3.1: Allgemeines Blockschaltbild der Hardware-Architektur Bei der Vorevaluierung und Entwicklung der “Proof-of-Concept”-Lösung wurden bewusst Sen- soren gewählt, die von verschiedenen BeagleBone-Einheiten angesprochen werden sollen, um alle Einsatzgebiete bzw. die Vielfältigkeit der BeagleBone-Hardware zu demonstrieren undMus- terlösungen zu den verschiedenen Einheiten zur Verfügung zu stellen. Beispielsweise kann bei BeagleBone der “Licht zu Frequenz-Umwandler - TSL235” [Tex 94] verwendet werden und di- rekt an die GPIO-Einheit angeschlossen werden (analog zum Bewegungsmelder). Stattdessen 52 wurde ein einfacher Fotowiderstand direkt an einen AD-Wandler angeschlossen. Es wurden somit folgende BeagleBone-Einheiten für die Verwendungmit den jeweiligen Senso- ren ausgewählt (siehe Abbildung 3.1): • PRU-Einheit in Verwendung mit dem Ultraschallsensor: Hierbei handelt es sich, wie be- reits in Kapitel 3.2.2 angesprochen, um eine programmierbare Echtzeit-Einheit, die es er- möglicht, zeitkritische Anwendungen unabhängig vom Linux-Kernel laufen zu lassen. Die- se Eigenschaft wird vom Ultraschallsensor benötigt, da sichergestellt werden muss, dass ein nahezu perfektes Rechtecksignal (Trigger) an den Sensor geliefert wird bzw. dieses zurückempfangen wird. Anhand der verstrichenen Zeit wird die Distanz ermittelt. Um die PRU-Einheit zu verwenden, muss das richtige “Device-Tree-Overlay” geladen werden. • GPIO-Einheit in Verwendung mit dem Bewegungsmelder: Die GPIO-Einheit ist eine vom Benutzer ansprechbare, digitale TTL-Schnittstelle mit einem “High”-Pegelwert von ca. 1,8 Volt. Zuerst wird festgelegt, ob der Port ein Aus- oder Eingang ist, danach kann die- ser gesetzt bzw. ausgelesen werden (z.B. durch das Schreiben bzw. Auslesen der Datei: “/gpio07/value”). • AD-Wandler in Verwendung mit dem Fotowiderstand: Der Fotowiderstand ändert je nach Lichteinstrahlung seinenWert. Mittels dem imBeagleBone integrierten AD-Wandler kann diedadurcherfolgte Spannungsänderung (Ohm‘schesGesetz) ausgelesenwerden.DieVer- wendung des AD-Wandlers benötigt eine Änderung des “Device-Tree-Overlays” (analog zur PRU-Einheit). Anders als bei GPIO kann der AD-Wandler nur ausgelesen werden (z.B. durch das Auslesen der Datei: “/in_voltage0_raw”). • I2C-Bus in Verwendung mit der Echtzeituhr: Der 1982 von der Fa. Philips entwickelte (re- lativ langsame) serielle Datenbus wird hauptsächlich für die Kommunikation zwischen verschiedenen Schaltungsteilen benutzt und soll direkt über das Betriebssystem ausgele- sen werden können. • USB-Bus/Cape-Host in Verwendung mit dem Video- bzw. Audiosensor: Auch hier werden die jeweiligen Daten durch das Auslesen der jeweiligen vom Treiber zur Verfügung ge- stelltenDatei (z.B. “/dev/video0”) erhalten. DieHardwaremuss imNormalfall nicht explizit beim System vom Benutzer registriert werden (Plug & Play). 53 3.5 Softwarearchitektur Es soll ein Objektorientiertes Framework für den Zugriff auf die Sensoren und die Kon󰅮iguration des Systems entwickelt werden. Um die Erweiterbarkeit zu ermöglichen, sollen de󰅮inierte Klas- sen (beispielsweise die Klasse “Sensor”) als Schnittstellen implementiert und zur Verfügung gestellt werden. Diese sollen in C++ als abstrakte Klassen mit virtuellen Funktionen realisiert werden. Vorbereitung Triggerung Aufnahme PostprocessingSpeicherung Abbildung 3.2: Allgemeines Funktionsdiagramm der Architektur Die einzelnen logischen Komponenten sind in Abbildung 3.2 ersichtlich. Im ersten Schritt (Vor- bereitung) wird die Kon󰅮iguration ausgelesen und der weitere Work󰅮low festgelegt. Damit wird ein Ereignis de󰅮iniert, das die Aufnahme startet (Triggerung). Außerdem wird festgelegt, wel- che Daten in welchem zeitlichen Abstand bzw. wie lange aufgenommen und imweiteren Schritt weiterverarbeitet werden sollen. Beim Schritt der Speicherung werden auch bestimmte Meta- daten zur erfolgten Aufnahme festgehalten. Im letzten Schritt (Postprocessing) kann eine Aus- wertung, beispielsweise eine Gesichtserkennung, oder eine Kodierung/Multiplexen der Video- /Audiodaten erfolgen. 54 Trigger loop Lichtsensor ADCManager getMessage() new(interval, duration…) messageInTreshold loop Bewegungssensor GPIOManager getMessage() new(interval, duration) messageInTreshold Videosensor new(fps, duration) stream Abbildung 3.3: Sequenzdiagramm des synchronen Datenzugriffs Für den Austausch der Daten zwischen den einzelnen Komponenten sind zwei Verfahren zu implementieren. Einerseits soll für sofortige Auswertungen der vom Sensor generierten Da- ten ein direkter Zugriff ermöglicht werden, beispielsweise “getMessage()” eines Bewegungs- melders (synchron). Andererseits soll ein sequentieller Zugriff auf die erstellten Daten mög- lich sein (asynchron). Je nach Aufgabenstellung können aufgenommene Daten beispielsweise nacheinander einem dafür vorgesehenen Thread (“Postprocessor”) übergeben werden, wäh- rend der direkte Zugriff auf Daten zwischen Sensor undTrigger ermöglichtwerden soll. Hier soll ein Queueing-Mechanismus bzw. eine auf Nachrichten basierende Datenübertragung vorgese- henwerden. Eine Queue (FIFO) ist nicht auf einen bestimmten Daten- bzw. Objekttyp festgelegt, sondern kann durch den Benutzer angepasst werden. Diese zwei Prozesse (direkter Zugriff auf Daten bzw. Zugriff über eine Queue) werden in den Abbildungen 3.3 und 3.4 dargestellt. 55 Main loop Trigger Queue new()new(configuration) Videosensor Postprocessor new(interval, queue, duration) startPostproccessor() queue startTrigger() getMessage() push(message) pop() message Abbildung 3.4: Sequenzdiagramm des asynchronen Datenzugriffs 3.5.1 Modellierung Zur Erstellung des Klassenmodells wurde die Anforderungsbeschreibung hinsichtlich Objekt- klassen, ihrer Attribute und ihrer Beziehungen untersucht. Ein Klassendiagramm ist in Abbil- dung 3.5 dargestellt3. Alle in den Anforderungen de󰅮inierten Sensoren für die Datenaufnahme sollen basierend auf dem Sensor-Interface au󰅮bauen. Bei den Benutzer-Algorithmen soll ein Bei- spielalgorithmus (z.B. Gesichtsdetektion) realisiert werden. Ergebnisse der Aufnahme werden in einem abstrakten “Stream”-Datentyp abgelegt. Streams (z.B. Audio oder Video) enthalten ne- ben Messwerten auch Metadaten und können zu einem “Medium” verknüpft werden. Sensor- daten können direkt abgerufen (“getMessage()”) oder einer Queue (“setQueue()”) zugewiesen werden. 3Aus Platzgründen sind nicht alle “Setter und Getter”-Methoden angegeben. Es werden stattdessen nur Attribute angegeben (wie auch bei den Interfaces “Sensor” und “userAlgorithm”). 56 Videosensor +video():constructor +getSingleFrame(imageType) +getVideoStream() -frame_count +width +height +library +actualFPS +imageType PRU, I2C,1 +log() +warning() +error() +loglevel Logger +media(stream, metadata):constructor +createMedia() +deleteMedia() +addStream() +deleteStream() +addMetadata() +deleteMetadata() +open() +close() +isOpened() +state +location Media +metadata():constructor +update() +delete() +height +width +timestamp +interval +duration +format Metadata +exception():constructor +toString() +throw() Attribute Exception +encode(stream) +encode(media) +decode(stream) +decode(media) +process() -buffer #mat -*inputqueue -*outputqueue Postprocessor +sensor():constructor #initialize() #close() #processData() +isRuning() +startCapturing() +stopCapturing() +get*Data() +getMessage() +putData() +type #name/device #state #duration #interval #sampleRate -buffer -powerUsage -exportToQueue -*queue << interface >> Sensor +stream():constructor +open() +close() +write() +isOpened() +state +location +format Stream +configuration(stream):constructor -parseXML() +getNodeCount() +createXML() +addNode() +addAttribute() +parser +stream +triggers, postprocessors, sensors Configuration -readConfiguration() -startTrigger() -startSensor() -startPostprocessor() +main() Main -configuration -sensor -trigger -postprocessor -queues toggleOutput() +value -direction -filestream GPIO +getIntResult() +getBoolResult() +getMatResult() +getQueue() #mat minTreshold maxThreshold << interface >> userAlgorithm +getIntResult() +getBoolResult() +getMatResult() +getQueue() #mat minTreshold maxThreshold Facedetector +getIntResult() +getBoolResult() +getMatResult() +getQueue() #mat minTreshold maxThreshold User Implemented calls 0..* 1..* 0..1 1..* 0..1 1..* 0..1 0..* +queue():constructor +push() +pop() +tryPop() +size() +empty() +swap(queue) -value -size Queue +trigger(sensor, algorithm):constructor +setEvents() +loop() +isTrue() +start +stop +interval +sensor +algorithm -*queue Trigger calls 0..* 0..1 Abbildung 3.5: Klassendiagramm 57 3.5.2 Herausforderungen Durch die Limitierungen der Hard- und Software im Embedded-Bereich (siehe Kapitel 2) ist zu erwarten, dass es sowohl bei derDatenakquisition als auch bei der Auswertung zu Performance- Problemen kommen kann. Es wird versucht, diese Probleme durch Optimierung der verwende- ten Bibliotheken und Komponenten zu lösen. Bei der Synchronisierung der Daten sollen even- tuell auftretende Ausfälle (z.B. einzelne Framedrops bzw. fehlende Messwerte) beispielsweise durch die Anpassung an die tatsächlich aufgenommenen Anzahl der Bilder/Messwerte berück- sichtigt werden. Verarbeitungsgeschwindigkeit Da bei der Aufnahme von hochau󰅮lösenden Video- und Audiodaten sehr große Datenmengen entstehen können, soll eine möglichst ef󰅮iziente Komprimierung verwendet werden. Es soll zu- demmöglich sein, eineDekomprimierung für jedes Einzelbild isoliert (keine P, B-Frames) durch- zuführen und dieses direkt in das OpenCV-Format (cv::Mat) zu bringen. Die Möglichkeit einer “On-the-Fly”-Komprimierung direkt auf der Kamera (Logitech C920) soll erörtert werden, um den Prozessor zu entlasten. Nebenläu󰅯igkeit Um die Nebenläu󰅮igkeit zu ermöglichen, soll das System Multithreading unterstützen. Dies ist vor allem für die Optimierung der Auslastung und für eine je nach Zielsetzung ausgeglichene Ressourcenverteilung notwendig. Zu diesem Zweck soll die C++11 Multithreading-Bibliothek verwendetwerden. Da unter Umständen die Verwendung von ein und derselben Ressource (z.B. Bewegungssensor) nur von einer Programminstanz gleichzeitig erfolgen darf, ist dies bei der Implementierung zu berücksichtigen. Synchronisation Um eine Synchronisierung der Daten zu ermöglichen, soll eine genaue Protokollierung durch- geführt werden (z.B. Timestamps der einzelnen Datenpunkte). Bei der gleichzeitigen Aufnahme von Video- und Audiodaten muss die Gesamtaufnahme beim Multiplexverfahren an die jeweils 58 kürzereEinzelaufnahmeangepasstwerden. Auchhierfür ist eineProtokollierungder tatsächlich aufgenommenen Bilder nötig. In Kapitel 4 soll eine Evaluierung hinsichtlich der auftretenden Synchronisationsprobleme erfolgen. 3.6 Kon󰅯iguration Die Kon󰅮iguration des Systems wird über ein XML durchgeführt. Dieses wird beim Starten des Programms automatisch geladen. Zusätzlich ist ein interaktives Menü für Debugging und Ent- wicklungszwecke geplant. Für die Kon󰅮iguration wurden im XML folgende Knoten de󰅮iniert: • Recording: Festlegung des Aufnahmemodus (z.B. “On-Detection”: Bei einfacher Sensor- /Zeit-Triggerung, “Use-Case-1'’: Benutzerde󰅮inierter Modus - beispielsweise für komple- xe Triggerungsmechanismen, z.B. Triggerung durch zwei verschiedene Sensoren (siehe Abbildung 1.1). • Sensor: Einstellungen des verwendeten Sensors (z.B. Au󰅮lösung, Format, Aufnahmedau- er). • Trigger: Sensor, derdasAufnahme-Ereignis anstoßt sowie Start- undStopp-Zeitpunkt bzw. Intervall de󰅮iniert (z.B. Bewegungssensor mit Sekundenintervall). • Postprocessor: Wie sollen die Datenweiterverarbeitet werden (z.B. durch Gesichtserken- nungsalgorithmen oder Multiplexing von Video- und Audio-Streams)? Die Kon󰅮iguration des ersten Anwendungsfalls, der in der Einleitung beschrieben ist (siehe Ab- schnitt 1.3), würde somit wie folgt aussehen: 1 < record ing mode="use - case -1 " name=" l i g h t -motion - t r i g ge r " > 3 < t r i g ge r type = " l i g h t " treshold -min= " 0 .5 " treshold -max= " 1 .0 " s t a r t = " 20151118172100 " stop= " 20151217172100 " i n t e r v a l = " 10000 " / > 59 5 < t r i g ge r type = "motion " s t a r t = " 20151118172100 " stop= " 20151217172100 " i n t e r v a l = " 10000 " / > < t r i gger - operator operator = "AND" / > 7 < / record ing > Listing 3.1: Anwendungsfall 1: Eine nahezu durchgehende Videoaufzeichnung bei Tageslicht und in der Nacht nur eine Audioaufnahme bei durch Sensoren erkannter Bewegung. Der zweite Anwendungsfall aus Abschnitt 1.3 kannmit demgenerischen “On-Detection”-Modus wie folgt realisiert werden: 1 < record ing mode="on - de tec t i on " name="motion - t r i g ge r " > 3 5 7 < t r i g ge r type = " v ideo " algor i thm=" face - de tec t i on " width= " 320 " he ight = " 240 " treshold -min= "2 " treshold -max= "2 " s t a r t = " 20151108172100 " stop= " 20151217172100 " i n t e r v a l = " 5000 " / > 9 < / record ing > Listing 3.2: Anwendungsfall 2: Eine Video-Trigger gesteuerte Aufnahme mit beispielsweise einer Frequenz von einem Bild pro Sekunde und einem Objekt-Erkennungsalgorithmus, der eine Video- und Audioaufzeichnung auslöst, solange Objekte erkannt werden. Bei Anwendungsfall 2 ist der Vollständigkeit halber ein “Postprocessor”-Knoten angefügt, der aus den aufgenommenen Video- und Audiodaten eine kombinierte “mp4”-Datei erstellt. Der dritte Anwendungsfall aus Abschnitt 1.3 kann auch mit dem generischen “On-Detection”-Modus wie folgt realisiert werden: 60 1 < record ing mode="on - de tec t i on " name="motion - t r i g ge r " > 3 < t r i g ge r type = " time " i n t e r v a l = " 3000000 " / > < / record ing > Listing 3.3: Anwendungsfall 3: Durchgängige Videoaufzeichnung im Zeitraffer-Modus (ein Einzelbild je 5 Minuten). Die genaue Spezi󰅮ikation der Kon󰅮igurationssprache kann in der XML-Schema (XSD) Notation angegeben werden: 2 < xs :anno ta t i on > 4 sensor must be used e i t he r as t r i g ge r or in content < / xs:documentat ion > < / xs :anno ta t i on > 6 8 < xs :anno ta t i on > 10 t y pe : audio , d istance , l i g h t , motion , v ideo , time durat ion / extend format : s , m, h ( seconds , minutes , hours ) , once , none 12 < / xs:documentat ion > < / xs :anno ta t i on > 14 16 < xs :ex tens ion base= " x s : s t r i n g " > < x s : a t t r i b u t e type = " x s : s t r i n g " name=" type " use= " requ ired " / > 18 < x s : a t t r i b u t e type = " x s : s t r i n g " name=" format " use= " op t i ona l " / > < x s : a t t r i b u t e type = " xs : shor t " name=" width " use= " op t i ona l " / > 20 < x s : a t t r i b u t e type = " xs : shor t " name=" he ight " use= " op t i ona l " / > < x s : a t t r i b u t e type = " x s : f l o a t " name=" fps " use= " op t i ona l " / > 22 < x s : a t t r i b u t e type = " x s : s t r i n g " name=" durat ion " use= " op t i ona l " / > 61 < x s : a t t r i b u t e type = " x s : s t r i n g " name=" extend " use= " op t i ona l " / > 24 < x s : a t t r i b u t e type = " x s : s t r i n g " name=" store " use= " op t i ona l " / > < x s : a t t r i b u t e type = " xs : b y t e " name=" b i t " use= " op t i ona l " / > 26 < x s : a t t r i b u t e type = " x s : i n t " name=" samplerate " use= " op t i ona l " / > < / xs :ex tens ion > 28 < / xs:s impleContent > < / xs:complexType> 30 < / xs:element > 32 < xs :anno ta t i on > t y pe : audio , d istance , l i g h t , motion , v ideo , time 34 a lgor i thm: face - de tec t i on durat ion / extend format : s , m, h ( seconds , minutes , hours ) , once , none 36 < / xs:documentat ion > < / xs :anno ta t i on > 38 40 < xs :ex tens ion base= " x s : s t r i n g " > < x s : a t t r i b u t e type = " x s : s t r i n g " name=" type " use= " requ ired " / > 42 < x s : a t t r i b u t e type = " xs : shor t " name=" width " / > < x s : a t t r i b u t e type = " xs : shor t " name=" he ight " / > 44 < x s : a t t r i b u t e type = " x s : s t r i n g " name=" algor i thm " / > < x s : a t t r i b u t e type = " xs : b y t e " name=" treshold -min" / > 46 < x s : a t t r i b u t e type = " xs : b y t e " name=" treshold -max" / > < x s : a t t r i b u t e type = " xs : l ong " name=" s t a r t " / > 48 < x s : a t t r i b u t e type = " xs : l ong " name=" stop " / > < x s : a t t r i b u t e type = " xs : shor t " name=" i n t e r v a l " / > 50 < x s : a t t r i b u t e type = " x s : s t r i n g " name=" save - resu l t " / > < / xs :ex tens ion > 52 < / xs:s impleContent > < / xs:complexType> 54 < / xs:element > 56 < xs :anno ta t i on > operator format : AND, OR< / xs:documentat ion > 58 < / xs :anno ta t i on > 60 62 < xs :ex tens ion base= " x s : s t r i n g " > 62 < x s : a t t r i b u t e type = " x s : s t r i n g " name=" operator " use= " requ ired " / > < / xs :ex tens ion > 64 < / xs:s impleContent > < / xs:complexType> 66 < / xs:element > 68 < xs :anno ta t i on > t y pe : avmux , v ideo 70 a lgor i thm: face - de tec t i on < / xs:documentat ion > 72 < / xs :anno ta t i on > 74 < xs :ex tens ion base= " x s : s t r i n g " > 76 < x s : a t t r i b u t e type = " x s : s t r i n g " name=" type " use= " requ ired " / > < x s : a t t r i b u t e type = " x s : s t r i n g " name=" algor i thm " / > 78 < x s : a t t r i b u t e type = " xs : b y t e " name=" treshold -min" / > < x s : a t t r i b u t e type = " x s : s t r i n g " name=" treshold -max" / > 80 < x s : a t t r i b u t e type = " x s : s t r i n g " name=" save - resu l t " / > < / xs :ex tens ion > 82 < / xs:s impleContent > < / xs:complexType> 84 < / xs:element > < / xs:sequence> 86 < x s : a t t r i b u t e type = " x s : s t r i n g " name="mode" use= " requ ired " / > < x s : a t t r i b u t e type = " x s : s t r i n g " name="name" use= " op t i ona l " / > 88 < / xs:complexType> < / xs:element > 90 < / xs:schema> Listing 3.4: Beschreibung der XML-Kon󰅮iguration in der XSD-Notation 63 64 Kapitel 4 Evaluierung und Ergebnisse In diesemKapitelwerdendie Ergebnisse der Systemevaluierung vorgestellt sowie das Erreichen der Ziele diskutiert. Es werden folgende Evaluierungen durchgeführt: • Evaluierung von einzelnen Sensoren und Aufgaben zuerst im Hinblick auf Verarbeitungs- geschwindigkeit. Hier werden Sensor-spezi󰅮ische Kennzahlen, wie beispielsweise die Au󰅮- lösung des Sensors oder maximale Sample-Rate des aufnehmenden Sensors, ermittelt. • Evaluierung des Stromverbrauchs bei der Aufnahme des jeweiligen Sensors, • Evaluierung des typischen Stromverbrauchs je nach Anwendungsfall, • Evaluierung des Software-Frameworks im Hinblick auf einfache Kon󰅮iguration und Ver- wendung. Hierbei werden kurze Quelltext- bzw. Kon󰅮igurations-Beispiele angegeben, um dies darzustellen. Eine Bewertung der “Proof-of-Concept”-Lösung inHinsicht auf Erfüllung der Anforderungen so- wie das Aufzeigen der Grenzen des Systems und deren Erweiterungsmöglichkeiten werden an- schließend in Kapitel 5 durchgeführt. 4.1 Videoaufnahme und Auswertung Die Echtzeit-Videoaufnahme ist eine der wichtigsten Anforderungen an die “Proof-of-Concept”- Lösung. Um diese zu ermöglichen, wurden bereits in der frühen Phase der Implementierung 65 Tests durchgeführt, um etwaige Engpässe bzw. Mängel zu entdecken. Dabei wurde festge- stellt, dass bei der unkomprimierten (RAW) Videoaufnahme (unabhängig von der Aufnahme- Software), sowohl mit dem BeagleBone Kamera-Cape als auch mit der USB-Kamera das Verar- beiten (Einlesen bzw. Schreiben) der Daten zu viel Zeit in Anspruch nimmt. Sequentielle I/O Performance-Messungen auf der SD-Karte (32 GB Lexar HC-MicroSD) haben beim Schreibzu- griff eine Datenrate von I11˘2 MB (n=3) pro Sekunde ergeben. Dies bedeutet, dass bei einer Full-HD-Au󰅮lösung nur maximal ein Bild pro Sekunde verarbeitet werden konnte. Auch was die Datenmenge betrifft, hat das aufgenommene 10 Sekunden-Video (10 FPS) eine Dateigröße von 1,2 Gigabyte, was nicht praktikabel ist. Um jedoch auch die Verarbeitungsgeschwindigkeit zu steigern und die CPU, die bei dem RAW- Format sehr beansprucht wird, zu entlasten, wurde die Videokomprimierung auf der USB- Kamera (Logitech C920), wie in Kapitel 3.5.2 vorgeschlagen, umgesetzt. Als Codierungsformat wurde Motion-JPEG (MJPEG) gewählt, da hier keine Inter-Frame Abhängigkeit besteht und ei- ne Decodierung der einzelnen Bilder in OpenCV selbst möglich ist. Um einen weiteren Ge- schwindigkeitszuwachs zu erzielen, wurde OpenCV in der neuesten Version (3.0) für die SIMD- Prozessoren-Unterstützung neu kompiliert. Weiters wurde die üblich verwendete Bibliothek für MJPEG-Codierung/Decodierung (libjpeg) durch die ebenfalls SIMD-optimierte Bibliothek (libjpegturbo) ersetzt. Hierbei konnte die Frame-Rate bei der Aufnahmen mit einer Au󰅮lösung von640x480Pixel bei über 50%signi󰅮ikant erhöhtwerden.Die Einzelbilderwurdenmittels der Video4Linux2-Bibliothek ausgelesen, da der vonOpenCV zur Verfügung gestellte Video-Grabber (Klasse “VideoCapture”) nicht auf bereits von der USB-Kamera codierte Daten zugreifen konn- te. Somit konnte die Videoaufnahme in einer Full-HD-Au󰅮lösung mit ca. 15 Bildern pro Sekunde erreicht werden. Wenn eine Weiterverwendung der Bilddaten im cv::Mat-Format und somit ei- ne anfallende Decodierung und Erstellung von der cv::Mat-Matrix erwünscht war, konnte eine Verarbeitungsgeschwindigkeit (inkl. Datenspeicherung) von ca. sieben Bildern pro Sekunde er- reicht werden (siehe Tabelle 4.1). Bei den Messwerten handelt es sich um den arithmetischen Mittelwert von drei Messungen (n=3). Mit der verwendeten MJPEG-Komprimierung entsteht bei einer Au󰅮lösung von 640 x 480 Pixel und 10 FPS eine Datenmenge von 1,7 GB pro Stunde. Die maximal mögliche verwendete SDHC- Kartengröße beträgt 32 GB und würde komplett für die Aufnahme zur Verfügung stehen, da sich das Betriebssystem im internen BeagleBone-Speicher be󰅮indet. Somit können mit diesen 66 Einstellungen maximal etwa 18 Stunden Videodaten aufgenommen werden. Im weiteren Verlauf wurden die Einzelbilder durch einen Gesichtserkennungsalgorithmus wei- terverarbeitet (siehe Kapitel 3.5). Der Gesichtserkennungsalgorithmus, der in OpenCV auf Basis der Arbeit von Viola et al. [Viola 04] implementiert wurde, benötigt für die Erkennung je nach Au󰅮lösung zwischen einer Sekunde und drei Sekunden. Somit muss diese Zeit zu den Werten in Tabelle 4.1 dazu gerechnet werden, um die Frame-Rate mit durchgeführter Gesichtserkennung zu erhalten. Verfahren (n=3) Bilder pro Sekunde [FPS] bei 640 x 480 Bilder pro Sekunde [FPS] bei 1280 x 720 Bilder pro Sekunde [FPS] bei 1920 x 1080 Unkomprimierte Aufnahme im RAW- (YUYV) Format 5,7 1,6 0,6 Aufnahme mittels H.264 “On-Camera”-Codierung 27,1 28,6 27,8 Aufnahme mittels MJPEG “On-Camera”-Codierung, Decodierung mittels libjpeg-Bibliothek 13,3 12,5 14,6 Aufnahme mittels MJPEG “On-Camera”-Codierung, Decodierung mittels libjpegturbo-Bibliothek 29,1 23,4 15,6 Aufnahme mittels MJPEG “On-Camera”-Codierung, Decodierung mittels libjpeg-Bibliothek und Erstellung eines cv::Mat-Objekts (OpenCV 2.0) 14,6 5,8 2,1 Aufnahme mittels MJPEG “On-Camera”-Codierung, Decodierung mittels libjpegturbo-Bibliothek und Erstellung eines cv::Mat-Objekts (OpenCV 3.0) 15,6 13,2 7,0 Tabelle 4.1: Evaluierung der Videoaufnahme und Verarbeitungsgeschwindigkeit 4.1.1 Rolle der OpenCV-Bibliothek Die OpenCV-Bibliothek konnte wider Erwartung nicht für die Videoaufnahme verwendet wer- den, da, wie bereits in Kapitel 4.1 erwähnt, die Hardwarebeschleunigung der USB-Kamera nicht unterstützt wird. Somit wurde die beschleunigte (komprimierte) Aufnahme zusätzlich mit der Video4Linux2-Bibliothek realisiert. Das Decodieren der Videodaten aus dem MJPEG- 67 Format, die Erstellung eines cv::Mat-Objekts sowie die Auswertung der Videodaten (Gesichts- erkennung) erfolgt mittels den von OpenCV zur Verfügung gestellten Methoden. Die Aufnahme ist auch in RAW (YUYV) sowie H.264-Formaten möglich. Die Datenübertragung zwischen der “Video”-Klasse, die für die Aufnahme zuständig ist, und der “Algorithm”-Klasse, die für die Aus- wertung der Daten zuständig ist, wurde mit einem Queueing-Mechanismus realisiert. Zuerst wird eine Queue mit dem gewünschten Datentyp (z.B. cv::Mat oder ocMessage1) erstellt und diese dem “Video”-Objekt zugewiesen. Jedes aufgenommene Frame kann im weiteren Schritt geholt und analysiert werden. Somit ist die Implementierung von Algorithmen, die sowohl auf nur einem Frame als auch auf mehreren aufeinanderfolgenden Frames basieren, möglich. 4.2 Audioaufnahme Wie in Kapitel 3.3.7 erwähnt, wurden zwei Audio-Bibliotheken zur Implementierung vorge- schlagen (PortAudio bzw. ALSA). Aufgrund einer besserenMultithreading-Unterstützungwurde die Umsetzungmit der PortAudio-Bibliothek realisiert. Beide Aufnahmegeräte, sowohl das Bea- gleBoneAudio-Cape als auch dasMikrofon derUSB-Kamera,werdenhierbei unterstützt. Derzeit wird bei der Audioaufnahme ein eigenständiger Thread aufgerufen, der die Audiodaten direkt in einen PortAudio-Puffer (Ringpuffer) speichert und diese erst beim Beenden des Aufnahmevor- gangs auf das Dateisystem schreibt. Um eine “gleichzeitige” Speicherung durchzuführen, wäre einweiterer Thread notwendig, der periodisch auf den Puffer zugreift und die Daten in die Datei schreibt2. Die Änderung wird als trivial erachtet, wurde aber aus Performance-Gründen nicht realisiert. Im Zuge der Evaluierung wurden Mono, 16 Bit-Audioaufnahmen bei einer Sample- Rate von 16kHz bis vier Stunden durchgeführt. Sowohl die PortAudio-Bibliothek als auch das Mikrofon der USB-Kamera unterstützen Sample-Raten bis 44 kHz mit einer Au󰅮lösung von 16- Bit bei einer Stereoaufnahme. Allerdings kann bei dieser Einstellung durch die hohe Datenmen- ge nur eine isolierte Audioaufnahme problemlos auf dem System erfolgen. Eine Komprimierung der Audiodaten (z.B. im MP3-Format) ist nur nachträglich mit einer entsprechenden Bibliothek möglich. 1Eigener Nachrichtendatentyp 2Quellcode siehe: http://portaudio.com/docs/v19-doxydocs/paex__record__file_8c_source.html 68 4.3 Bewegungserkennung Die Bewegungserkennung wurde, wie erwartet, mit einem PIR-Sensor, angeschlossen an die GPIO-Schnittstelle des BeagleBone, realisiert. Für die Datenübertragung zwischen dem PIR- Sensor und der GPIO-Schnittstelle wurde die Klasse “GPIO-Manager” implementiert, die auf dem Singleton-Entwurfsmuster basiert und Methoden zum Setzen und Auslesen des Zustands durch die “Motion”- (Sensor) Klasse ermöglicht. Die Bewegungwird zuverlässig unabhängig von Lichtverhältnissen erkannt. Der Sensor kannbis zur einer Sample-Rate vonüber 200Messungen pro Sekunde verwendet werden. Um eine zugesicherte, höhere Sample-Rate zu erhalten, ist ent- weder die Verwendung von Real-Time Methoden, womit wiederum Multithreading erschwert wird, oder die Verwendung der PRU-Einheit, da diese unabhängige Ressourcen zur Verfügung stellt, notwendig. Der maximale Einstrahlwinkel beträgt laut Recherche zwischen 80-90°. Die Bewegung wird noch in einer Entfernung von 7-10 Meter erkannt [Par 14]. 4.4 Distanzmessung Für die Distanzmessungwird die PRU-Einheit verwendet. Um diese zu nutzen, ist hierbei, wie in Kapitel 3.3.1 beschrieben, die Verwendung der “Device-Tree Overlays” notwendig. Da diese auf dem bisher verwendeten Linux-Debian ARMKernel 4.2.1 nicht mehr funktioniert haben, wurde einDowngrade auf Version “4.1.5-ti-rt-r10 ” durchgeführt3. Für das LadenundAusführendes se- paraten für die PRU-Einheit in C geschriebenen Quellcodes4 wurde die “PRU-Manager”-Klasse implementiert. Das “Device-Tree Overlay” muss vor der Ausführung des PRU-Programms gela- denwerden. Auch diese Aufgabewird, wenn nötig, vom “PRU-Manager” durchgeführt. DemBe- nutzer stehen, wie bei anderen Sensoren auch, die Methoden (z.B. “getDouble()”) zum Auslesen der Distanz in Zentimetern zu Verfügung.Wie imDatenblatt empfohlen, sollen für eine zuverläs- sige Messung ca. 60ms eingeplant werden, um das zurückgesendete Signal nicht mit dem neuen Trigger-Signal zu vermischen [elecfreaks.com 15]. Somit kann der Sensor bis zu einer Sample- Rate von 16 Messungen pro Sekunde verwendet werden. Allerdings verringert sich die Sample- Rate durchhäu󰅮igesAuslesenderPRU-Einheit sowiedas FormatierenundSchreiben (C++Befehl fprintf) der Ergebnisse und des Timestamps auf 8-12 Samples pro Sekunde. Der Einstrahlwinkel 3Siehe: http://www.embeddedhobbyist.com/2015/09/beaglebone-black-updating-device-tree-files/ 4PRU-Quellcode zur Verwendung des HC-SR04-Sensors: https://github.com/luigif/hcsr04 69 für eine zuverlässige Messung beträgt in etwa 15 bis 40°[elecfreaks.com 15][Cyt 13]. 4.5 Helligkeitsmessung Um bei BeagleBone eine analoge Eingabe zu ermöglichen, müssen hier ebenfalls “Device-Tree Overlays” verwendet werden. Der auf dem Board vorhandene AD-Wandler (“ti_am335x_adc”) muss in den Linux-Kernel geladen werden, bevor die analogen Signale ausgelesen wer- den können. Diese Aufgabe wird, wie bei den anderen Sensoren, von einer Singleton “ADCManager”-Klasse übernommen. Dem Benutzer werden für die Abfrage des Werts die Me- thoden der Klasse “Light” (z.B. “getInt()”) zur Verfügung gestellt. Geliefert werden relative Ände- rungen in dem vomAD-Wandler de󰅮inierten Bereich von 0 bis 4095 (“getInt()”) sowie auf einem Einheitsintervall abgebildeten Intervall (“getDouble()”), das die Werte in einem Bereich von 0 bis 1 zurückliefert. Als Schwellwert bei denMessungen zum StromverbrauchwurdenWerte von unter 0,5 als “Nacht” und darüber als “Tag” festgelegt. Das Sensor kann zuverlässig bis zur einer Sample-Rate von über 200 Messungen pro Sekunde verwendet werden, allerdings ist bei der relativ geringen Änderung der Helligkeit über den Tag verteilt auch eine Messung pro Minute ausreichend. 4.6 Nutzung der Sensoren im Software-Framework Kon󰅯iguration des Systems Um die Einfachheit des Software-Frameworks im Hinblick auf einfache Kon󰅮iguration und Nut- zung darzustellen, wird hier ein vollständiges Kon󰅮igurations-Beispiel sowie ein kurzer Quell- text, der die Verwendung des Software-Frameworks erläutert, gezeigt. Die Kon󰅮iguration des Systems ist im Listing 4.1 ersichtlich. 2 < record ing mode="on - de tec t i on " name="motion - t r i g ge r " > 4 70 6 8 < t r i g ge r type = " time " s t a r t = " 20160221150500 " stop= " 20160221200000 " i n t e r v a l = " 60000 " / > < t r i g ge r type = " v ideo " algor i thm=" face - de tec t i on " width= " 640 " he ight = " 480 " treshold -min= "1 " treshold -max= "1 " s t a r t = " 20151102125959 " stop= " 20151209172100 " i n t e r v a l = " 10000 " / > 10 < t r i gger - operator operator = "AND" / > 12 < / record ing > Listing 4.1: Vollständige Kon󰅮iguration des Systems. Beispiel zur Nutzung im Software-Framework Die Nutzung der wesentlichen Software-Komponenten im Sinne der Erweiterbarkeit, beispiels- weise Sensoren oder Benutzeralgorithmen, erfolgt auf Basis der Interfaces. Im Listing 4.2 ist die Nutzung des Software-Frameworks dargestellt. 1 / / Ers te l lung des Video -Sensor - Objekts mit den Parametern aus dem XML 3 Video v ideo ( VIDEO_DEFAULT_DEVICE , width , height , VIDEO_USE_V4L2 ) ; / / Aufnahmegereat - Standard : Logi tech USB-Kamera , Aufloesung und d ie verwendete B ib l i o t hek werden d e f i n i e r t . Neben Video4Linux2 i s t auch eine Aufnahme mit OpenCV möglich . Tr igger * v i d eo t r i g ge r = new Tr igger ( ) ; 5 FaceDetector * faceDetector = new FaceDetector ( ) ; Queue queue ; 7 v i d eo t r i g ge r -> setQueue (&queue ) ; 9 thread t _ t r i g g e r = v i d eo t r i g ge r -> s t a r t T r i g ge r (& video , faceDetector , i n t e r v a l , s ta r t , stop , tresholdMin , tresholdMax ) ; t _ t r i g g e r . detach ( ) ; / / Tr igger - Thread l a eu f t we i ter . Frames werden in d ie Queue gespe icher t und vom FaceDetector ausgelesen . 71 11 / / Ers te l lung des Audio -Sensor - Objekts mit den Parametern aus dem XML 13 Audio audio ( AUDIO_PORTAUDIO_DEFAULT_DEVICE , AUDIO_USE_PORTAUDIO , AUDIO_MODE_INPUT_ONLY , aud io_ca l lback ) ; / / PortAudio fü r d ie Eingabe nutzen . Funkt ion aud io_ca l lback wird aufgerufen sobald eine Aufnahme begonnen hat ( d e r z e i t n i ch t in Verwendung ) 15 Stream stream(&audio , fa lse , true , format ) ; / / Sensor , i s t lesbar , i s t beschreibbar , Format z .B . RAW (PCM) 17 / / Speicherung eines Audio -Streams mit den Parametern aus dem XML stream . open ( STREAM_DIRECTION_WRITE ) ; 19 audio . writeAudioStream ( stream , samplerate , durat ion , AUDIO_INPUT_MONO , AUDIO_DEFAULT_INPUT_FRAMES ) ; / / Samplerate aus dem XML, v o r d e f i n i e r t e Mono aufnahme , Frames pro Buf fer d ie vom Audio - Cal lback g e l i e f e r t werden ( PortAudio ) stream . close ( ) ; 21 / / Ers te l lung des Motion -Sensor - Objekts - jeder Sensor kann als Tr igger ( s iehe oben ) aufgerufen werden , a ls auch deren Wert d i r e k t im Programmcode ausgelesen werden . z .B . : 23 Motion motion ; 25 i f ( motion . getBool ( ) ) { / / Bewegung erkannt . 27 } 29 Distance d is tance ; i f ( d is tance . getDouble ( ) ) { 31 / / L i e f e r t d ie Entfernung des Objekts in cm zurueck . } 33 L igh t l i g h t ; 35 i f ( l i g h t . getDouble ( ) ) { / / L i e f e r t d ie He l l i g k e i t zueruck . 37 } Listing 4.2: Verwendung der Sensoren zur Triggerung oder Aufnahme 72 Im Listing 4.2 sind die Erstellungen der Sensor-Instanzen und der darauf basierende Trigger-Instanzen dargestellt. Es müssen Instanzen der “Video”, “Trigger” und “Algorithm” (FaceDetector)-Objekte erstellt werden. Dem Trigger wird eine Queue zugewiesen und es wird ein eigenständiger Trigger-Thread gestartet. Der “Video”-Sensor wird somit unter Berücksichti- gung der Start- und Stopp-Zeit sowie dem imXML festgelegten Intervall als Trigger de󰅮iniert. Die Software-Architektur samt demQueuing-Mechanismuswurde bereits in Kapitel 3.5 besprochen und konnte wie gewünscht umgesetzt werden. Ab der Zeile 12 wird die Instanzierung und die Speicherung (“writeAudioStream”) eines vom “Audio”-Sensor erzeugten “Streams” vorgezeigt. Das Schreiben in einen “Stream” kann auch für die ab der Zeile 24 gezeigten Sensoren (für Bewegungs- oderHelligkeits-Messung) durchgeführt werden. Hier sind jedoch Beispiele gezeigt, wie man Augenblickswerte abfragen kann. Ausgabe des Systems Bei den Sensordaten, die nur eine lesbare ASCII-Textdatei erzeugen, wird neben dem Start- und Stopp-Zeitpunkt sowie der gewünschten Sample-Rate zusätzlich zu jedemDatenpunkt ein Index sowie ein Timestamp gespeichert. Im Logging-Mechanismus werden zudemWarnungen ausge- geben, sobald ein Datenverlust eingetreten ist. Ein Auszug der Ausgabe einer Distanzmessung kann dem Listing 4.3 entnommen werden. 1 s t a r t : Wed Feb 24 21 :54 :29 2016 / samplerate : 10 ( samples per second ) [ 0 / 02 24 21 :54 :29 2016 ] - >213.40 cm 3 [ 1 / 02 24 21 :54 :29 2016 ] - >166.44 cm [2 / 02 24 21 :54 :30 2016 ] - >121.13 cm 5 [ 3 / 02 24 21 :54 :30 2016 ] - >165.18 cm [4 / 02 24 21 :54 :30 2016 ] - >194.93 cm 7 [ 5 / 02 24 21 :54 :30 2016 ] - >129.16 cm [6 / 02 24 21 :54 :30 2016 ] - >129.59 cm 9 [ 7 / 02 24 21 :54 :30 2016 ] - >130.10 cm [8 / 02 24 21 :54 :30 2016 ] - >233.88 cm 11 [ 9 / 02 24 21 :54 :30 2016 ] - >93.62 cm end : Wed Feb 24 21 :54 :30 2016 / samples : 10 Listing 4.3: Beispielhafte Ausgabe einer Distanzmessung 73 4.7 Echtzeituhr Wie in Kapitel 3.3.3 vorgeschlagen, wurde die Echtzeituhr auf Basis des DS1307-Moduls reali- siert. Die Uhrzeit wird zusätzlich beim Starten des Linux-Programms über das “Network Time Protocol” mit einer entfernten Uhr synchronisiert. 4.8 Synchronisation Bei der Aufnahmeder Sensordaten, bei denen die gesicherte, gleichmässige periodische Aufnah- me nicht möglich ist (z.B. durch Verwendung vonMultithreading) sowie auch keine Zeitstempel für jeden einzelnen Messwert erfasst werden können, muss davon ausgegangen werden, dass zwischen den verschiedenen Sensoren eine Asynchronität entstehen kann. Dies betrifft sowohl Audio- als auch Videodaten. Eine Asynchronität der Video- und Audiodaten ist vor allem nach der Erstellung einer gemein- samen Datei, die sowohl eine Video- als auch Audiospur enthält, sofort ersichtlich. Während die Audioaufnahme bei der “Proof-of-Concept”-Lösung unabhängig von der Qualität (z.B. Da- tentyp, Bits, Anzahl der Kanäle) konstant bleibt, kommt es vor, dass bei der Videoaufnahme die erwünschte Anzahl an Bildern pro Sekunde wegen fehlender Leistungsfähigkeit der Hardware (CPU-Geschwindigkeit, I/O-Geschwindigkeit) nicht erreicht werden kann. Hier muss eine nach- trägliche Korrektur vorgenommenwerden. Zum einen kann die Synchronisation der Video- und Audiodaten anhand der tatsächlichen Anzahl der Bilder pro Sekunde erfolgen und zum ande- ren kann die Länge der Gesamtaufnahme an die kürzere Spur von beiden (Audio oder Video) angepasst werden. Bei der “Proof-of-Concept”-Lösung wurde eine solche Asynchronität anhand der audiovisuel- len Evaluierung einer Audio- und Video-Aufnahme eines mit Untertiteln versehenen abgespiel- ten Videos festgestellt. Die Evaluierung hat ergeben, dass bei längeren Aufnahmen (ab etwa 25 Minuten) eine Asynchronität entsteht und diese bei Aufnahmen von mehreren Stunden sogar einige Sekunden betragen kann. Bei allen anderen Sensoren kann die Asynchronität durch die Verwendung von Zeitstempeln bei jedemMesswert bei der Auswertung berücksichtigt werden. 74 Das Erstellen einer gemeinsamen Video- und Audio-Datei (Multiplexen) wird von der “Proof-of- Concept”-Software über einen externer Prozess “avconv” in einem separaten Thread (über die “posix_spawn”-Funktionalität) aufgerufen. Dabei werden die zwei Spuren sowie die gewünsch- ten Parameter zur Transcodierung übergeben. 4.9 Stromverbrauch Die Evaluierung des Stromverbrauchs wurde in zwei Bereiche unterteilt. Zum einen wurde der Stromverbrauch je nach Trigger bzw. Aufnahmesensor ermittelt und zum anderen je nach An- wendungsfall (siehe Szenarien aus Kapitel 1.3). Hier ist besonders derMittelwert des Stromver- brauchs über eine längere Zeitspanne interessant. 4.9.1 Messverfahren Um den Mittelwert des Stromverbrauchs in verschiedenen Verarbeitungsstufen des Systems, beispielsweise bei der Triggerung, der Aufnahme oderWartezeit, zu erhalten, ist hier eine Lang- zeitmessung amzielführendsten. Hier kannbeispielsweisemit einemVolt- bzw. Amperemeter in sehr kurzen Intervallen ein Messwert abgelesen werden oder ein Leistungsmessgerät verwen- det werden. Da der Stromverbrauch übermehrere Stunden ermittelt werden soll, wurde hierbei als Messinstrument das handelsübliche 230 Volt Leistungsmessgerät “COST CONTROL 3000” der Firma Basetech verwendet [Basetech 09]. Die Messergebnisse wurden durch Stichproben- Messungen mit einem Volt- bzw. Amperemeter evaluiert. Das für die Stromversorgung verwen- dete Netzteil besitzt laut Datenblatt einenWirkungsgrad von 70%undmuss beimMessergebnis berücksichtigt werden [viv 16]. Alle Testläufe wurden n-mal wiederholt. Wenn es sich um keine Einzelmessungen handelt, sind bei den Messwerten jeweils die Mittelwerte sowie Standardabweichungen über die n- Messungen angegeben. Um den Verbrauch in elektrischer Leistung (P) zu erhalten, muss die vomMessgerät in Kilowattstunden angegebene Energie (E) wie folgt umgerechnet werden: P = 1000 * E / t (4.1) 75 4.9.2 Ergebnisse In Tabelle 4.2 sind die Ergebnisse der Messung aufgelistet. Zuerst werden die Messungen pro Anwendungsfall (drei Messungen über 24 Stunden) und danach pro Sensor angegeben. Um den Stromverbrauch je nach Belastung des Systems zu ermitteln wurden alle Anwendungsfälle in zwei verschiedenen Intensitäten ausgeführt. Bei “moderaten” Anwendungenwurde die Triggerung alle fünf Sekunden ausgelöst und die Dau- er der Video- und Audioaufnahme beträgt 30 Sekunden. Bei “intensiven” Anwendungen wurde die Triggerung alle drei Sekunden ausgeführt und die Aufnahmedauertmindestens eine Stunde. Die CPU-Geschwindigkeit wird bei einer Bildwiederholungsrate unter acht Bildern pro Sekunde und einer Au󰅮lösung bis 640 x 480 per Software auf 300 MHz beschränkt, um den Stromver- brauch niedrig zu halten. Bei höheren Au󰅮lösungen bzw. Bildwiederholungsraten wird diese auf das Maximum von 1000MHz gesetzt. Bei der Benutzung aller anderen Sensoren wurde die Pro- zessorgeschwindigkeit auf 300 MHz gesetzt. Wie aus den Ergebnissen der Evaluierung ersichtlich ist, benötigt die Aufnahme mit einer sehr langen Video- und Audiodauer (“intensiv”) sowie häu󰅮iger Triggerung deutlich mehr Ressour- cen. Dies ist vor allem mit der hohen Prozessorauslastung zu begründen und wird bei Anwen- dungsfall 2, bei dem eine häu󰅮ige Gesichtserkennung durchgeführt wird und bei dem der Strom- verbrauch am Höchsten ist, deutlich. Jedoch liegt der Stromverbrauch unterhalb von den in den AnforderungengesetztenWerten. Sowohl die geforderten0,12KilowattstundenproTag als auch die maximale Leistungsaufnahme von 8 Watt werden deutlich unterschritten. Besonders her- vorzuheben ist, dass bei der Aufnahme von mehreren Sensoren der Stromverbrauch nur subli- near steigt. Auch dies ist besonders aus den Messungen des Stromverbrauchs aus den Anwen- dungsszenarien in Kapitel 1.3 ersichtlich. Somit kann vor allem eine reine Überwachungstätig- keit ohne Datenanalyse am Stromsparendsten durchgeführt werden können. 76 Anwendungsfall / Sensor Messung 1 Messung 2 Messung 3 Mittelwert Energie [kWh]a Leistung [W]b Energie [kWh]a Leistung [W]b Energie [kWh]a Leistung [W]b Energie [kWh]a Leistung [W]b Anwendungsfall 1 “moderat”, n=3; Auslösungen: I12 ˘2; c 0,014 0,58 0,014 0,58 0,021 0,875 0,016 0,68 Anwendungsfall 1 “intensiv”, n=3; Auslösungen: I14, 3 ˘1, 52; d 0,049 2,04 0,035 1,45 0,042 1,75 0,042 1,75 Anwendungsfall 2 “moderat”, n=3; Auslösungen: I28 ˘9, 89;e 0,014 0,58 0,021 0,875 0,028 1,16 0,021 0,87 Anwendungsfall 2 “intensiv”, n=3; Auslösungen: I12, 3 ˘2, 51; f 0,049 2,04 0,035 1,48 0,042 1,75 0,042 1,75 Anwendungsfall 3 “moderat”, n=3; Auslösungen: I2880 ˘0; g 0,014 0,58 0,021 0,875 0,021 0,875 0,018 0,77 Anwendungsfall 3 “intensiv”, n=3; Auslösungen: I8640 ˘0; h 0,028 1,16 0,035 1,45 0,035 1,45 0,032 1,36 Video, 640 x 480 25 FPS - MJPEGi 0,042 1,75 0,035 1,45 0,042 1,75 0,039 1,65 Audio, Mono 16 Biti 0,021 0,87 0,021 0,87 0,028 1,16 0,023 0,97 Distanz, 1 Sample pro Sekundei 0,018 0,75 0,022 0,93 0,019 0,81 0,02 0,83 Bewegung, 1 Sample pro Sekundei 0,017 0,72 0,021 0,87 0,021 0,87 0,019 0,82 Helligkeit, 1 Sample pro Sekundei 0,021 0,82 0,017 0,72 0,021 0,87 0,019 0,82 Tabelle 4.2: Evaluierung des Stromverbrauchs aEnergieverbrauch pro Tag (24h) bNach Formel 4.1 cTrigger: Distanz & Helligkeit: 60 Sekunden; Video: 1h / 640 x 480 3 FPS - MJPEG dTrigger: Distanz & Helligkeit: 3 Sekunden; Video: 1h / 640x480 10 FPS - MJPEG eTrigger: Gesichtserkennung alle 5 Sekunden; Video: 30 Sek. / 640x480 10 FPS - MJPEG; Audio: 30 Sek. / Mono 16 Bit; Distanz & Helligkeit: 1 Min. / 1 Sample pro Sekunde; Bewegung: 10 Sek. / 1 Sample pro Sekunde fTrigger: Gesichtserkennung alle 3 Sekunden; Video: 1h / 640x480 10 FPS - MJPEG; Audio: 1h / Mono 16 Bit; Distanz & Helligkeit & Bewegung: 1h / 1 Sample pro Sekunde gTrigger: alle 30 Sekunden; Video: 1s / 1280x720 1 FPS - MJPEG hTrigger: alle 10 Sekunden; Video: 1s / 1280x720 1 FPS - MJPEG in=3; Trigger: einmalig; Aufnahme: 24h des jeweils angegebenen Sensors (ausgenommen Audio - hier wurde die Aufnahme jede 4h gestartet) 77 78 Kapitel 5 Zusammenfassung Das Ziel dieser Diplomarbeit war, das Potential und die Machbarkeit eines möglichst autono- men und vom Benutzer kon󰅮igurierbaren Überwachungssystems mit handelsüblichen Kompo- nenten zu evaluieren sowie eine preisgünstige “Proof-of-Concept”-Lösung zu entwickeln. Das System soll im Stande sein, getriggert durch verschiedene Sensoren, Aufnahmen zu starten und ist ursprünglich für den Zweck der Tierbeobachtung im Feld gedacht. Daher lag der Fokus in der Entwicklung eines Systems, das möglichst stromsparend funktionieren soll. Im Rahmen der Diplomarbeit wurden zuerst verschiedene Software- und Hardware- Plattformen evaluiert mit denen die Anforderungen umgesetzt werden konnten. Nachfol- gend wurde eine “Proof-of-Concept”-Lösung entwickelt und ausführlich getestet. Nach der ersten Vorevaluierung der Hardware-Plattformen (es sind über 120 verschiedene eingebet- tete Systeme am Markt) wurde letztlich aus drei verschiedenen Systemen das BeagleBone Black ausgewählt. Nach der Auswahl der Komponenten (Sensoren) wurde die Hardware- und Software-Architektur entworfen undmit der Implementierung begonnen. Die Implementierung des Software-Frameworks, das aus ungefähr 9.500 “Lines of Code” (LOC) besteht, wurde in C++ unter Verwendung der Bibliotheken Video4Linux2, PortAudio, libxml++ sowie der OpenCV- Bibliothek für maschinelles Sehen durchgeführt. Die Kon󰅮iguration des Systems kann mittels einer XML-Kon󰅮igurationsdatei durchgeführt werden. Anschließend wurde eine Evaluierung vor allem im Hinblick auf die Verarbeitungsgeschwindigkeit und Stromaufnahme durchgeführt sowie deren Ergebnisse diskutiert. Im Folgenden werden die Erkenntnisse aus der Arbeit zusammengefasst, limitierende Faktoren identi󰅮iziert und zukünftige Erweiterungen erörtert. 79 5.1 Ergebnisse Sowohl die Audio- als auch Videoaufnahme konnte im gewünschten Umfang realisiert werden. Eine durchgängige Aufnahme mit einer Au󰅮lösung von 640 x 480 Pixel und 10 FPS sowie zu- sätzlichen Audiodaten kann bei einer Benutzung von SD-Speicherkarten (Maximum von 32 GB laut SDHC-Standard) etwa16Stundenbetragen. EineErweiterungdes Speicherplatzes kannbei- spielsweise mit einem externen Datenträger durchgeführt werden (z.B. USB-Festplatte, Netz- werkspeicher). Die Synchronizität zwischen der Video- und Audiospur ist bei Aufnahmen nur bis zu einer halben Stunde gegeben. EineUnterbrechungundnochmaligeDurchführungderAuf- nahme (in eine neue Datei) würden das Problem beheben. Parallel zur Video- und Audioaufnah- me kann auch eine gleichzeitige Auswertung der Daten durchgeführt werden, jedoch ist ab ei- ner gewissen Datenmenge (bzw. Verarbeitungszeit) eine Serialisierung dieser Aufgabe empfeh- lenswert. Auch bei der Verwendung von anderen, im Rahmen dieser Arbeit evaluierten Senso- ren konnten alle Anforderungen erfüllt werden. Hier wurde das System je nach Anwendungsfall und für jeden Sensor separat evaluiert. Nebender Ermittlung der Verarbeitungsgeschwindigkeit pro Sensor wird auch eine Gesamtevaluierung durchgeführt wurde. Diese Vorgangsweise wur- de auch für den Stromverbrauch durchgeführt. Durch den sublinearen-Stromverbrauch (siehe 4.9.2) ist bei dem entwickelten System im Schnitt ein Verbrauch zwischen I0, 68 ˘0, 16 Watt und I1, 75 ˘0, 29Watt (n = 3), je nach Anwendungsfall und den verwendeten Sensoren, zu er- warten. Bei Volllast ist einemomentane Leistungsaufnahmevon3,5Watt gegeben, die allerdings in denAnwendungsfällen nie erreichtwurde. Somit kanndas umgesetzte Systemals Konkurrenz zu anderen weitaus teureren Systemen bzw. als Ersatz zu der eingestellten LeanXcam dienen. Zusammenfassend lässt sich sagen, dassmit der “Proof-of-Concept”-Lösung alle Anforderungen erfolgreich umgesetzt werden konnten. Es konnte eine preisgünstige Hardware zusammenge- baut werden sowie ein frei verfügbares Open-Source-Framework geschaffen werden, das alle Anforderungen aus Kapitel 3.1 erfüllt. Der Stromverbrauch des Systems und der Sensoren ist selbst bei der Videoaufnahme dank der Videokomprimierung, die in der USB-Kamera durchge- führt wird, sogar niedriger als in der Vorevaluierung angenommen (siehe Kapitel 3.2.1). Einzig bei längeren, gleichzeitigen Video- und Audioaufnahmen kommt es nach einer gewissen Zeit zu einer Asynchronität zwischen den beiden Spuren. 80 5.2 Grenzen des Systems und Erweiterungsmöglichkeiten DurchdieAuswahl der Plattformundder Sensoren sind bewusst Entscheidungen getroffenwor- den, die Limitierungen mit sich bringen. Beispielsweise ist für die Distanzmessung aufgrund niedriger Kosten ein Ultraschallsensor gewählt worden, obwohl die maximal zuverlässig mess- bare Distanz (0 bis ca. 6 Meter) verglichen mit einem Lasersensor (bis 50 Meter) relativ gering ist. Auch die Verarbeitungsgeschwindigkeit ist bei einer Full-HD-Aufnahme mit sieben Bildern pro Sekunde relativ gering. Hier sind de󰅮initiv Verbesserungsmöglichkeiten vorhanden. Eine weitere Limitierung ist die bei der Video- und Audioaufnahme entstandene Asynchronität und softwareseitig eine fehlende Priorisierung der laufenden Threads, da die Lösung dieser Aufgabe mit der bisher verwendeten C++11-Threading Bibliothek nicht möglich ist. Möglicherweise können die Probleme der Verarbeitungsgeschwindigkeit und Asynchronität al- leine mit neueren, leistungsfähigeren Modellen der BeagleBone-Hardware behoben werden. Auch die Verwendung von separaten Threads zur “zeitnahen” Speicherung von Audiodaten, wie bereits in Kapitel 4.2 beschrieben, könnte ein Ansatz sein, um die Asynchronität zu beheben. Als softwareseitige Erweiterung kann die Speicherung derMetadaten sowie die Katalogisierung der Ergebnisse beispielsweise über eine relationale Datenbank (z.B. SQLite1) erfolgen, um die Auswertungen der Daten leichter zu ermöglichen. Beispielsweise könnte man damit nur Daten abrufen, in denen eine bestimmte Tierart erkannt worden ist. Neben den Erweiterungsmöglichkeiten des Software-Frameworks, sind die Erweiterungsmög- lichkeiten auch hardwareseitig vielfältig. Neben den bereits im vorherigen Abschnitt angespro- chenen Sensoren zur Distanzmessung, kann auch die Einbindung eines Monitor-Capes und die Unterstützung einer gra󰅮ischen Benutzerschnittstelle (inkl. Touch-Bedienung) je nach Anwen- dungsgebiet vorteilhaft sein. Somit wäre bei der Benutzung einer gra󰅮ischen Benutzerschnitt- stelle auch im Feld eine Kon󰅮iguration des Systems möglich. Weiters kann das System um die bereits in Kapitel 3.3 vorgeschlagenen Power-Capes zur Unterstützung des Ladevorgangs er- weitert werden. Aber auch die Entwicklung eines wasserdichten Gehäuses für eine Verwen- dung im Aussenbereich wäre möglich. Hier kann auch der Einsatz von IR-Dioden zur Beleuch- tung bei Nachtaufnahmen von Vorteil sein. Dabei bietet es sich an neben den frei verfügbaren BeagleBone-Gehäusen ein mit 3D-Druck-Verfahren angepasstes Gehäuse zu erstellen, dass auf 1Die SQLite-Bibliothek lässt sich direkt in die Anwendungen integrieren, sodass keine weitere Server-Software benötigt wird. 81 die jeweiligen Komponenten (Kamera, Sensoren, IR-Dioden, Touch-Display) abgestimmt ist. 82 Abbildungsverzeichnis 1.1 Flussdiagramm - Anwendungsfall 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.1 Microsoft Research SenseCam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2 Viseum IMC Kamera-Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.3 LeanXcam Open-Source Kamera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.4 Elphel Model 353 Kamera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.5 CMUcam 5 - Pixy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.6 Arduino Mega 2560 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.7 Raspberry Pi Rev. B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.8 BeagleBone Black . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.1 Allgemeines Blockschaltbild der Hardware-Architektur . . . . . . . . . . . . . . . 52 3.2 Allgemeines Funktionsdiagramm der Architektur . . . . . . . . . . . . . . . . . . 54 3.3 Sequenzdiagramm des synchronen Datenzugriffs . . . . . . . . . . . . . . . . . . . 55 3.4 Sequenzdiagramm des asynchronen Datenzugriffs . . . . . . . . . . . . . . . . . . 56 3.5 Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 83 84 Tabellenverzeichnis 1.1 Benötigte Sensoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.1 Vergleich der Komplettsysteme bzw. Entwicklungsumgebungen . . . . . . . . . . 31 2.2 Vergleich der Bibliotheken sowie deren Anwendung . . . . . . . . . . . . . . . . . 39 3.1 Anforderungen - Gesamtsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.2 Anforderungen - Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.3 Anforderungen - Sensoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.4 Anforderungen - Stromaufnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.5 Stromverbrauch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.6 Erweiterungsmöglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.1 Evaluierung der Videoaufnahme und Verarbeitungsgeschwindigkeit . . . . . . . 67 4.2 Evaluierung des Stromverbrauchs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 85 86 Literaturverzeichnis [Adafruit 15a] Adafruit. Addmusic to your arduino. Online-Quelle. https://learn.adafruit.com/ adafruit-wave-shield-audio-shield-for-arduino, 2016.02.28. [Adafruit 15b] Adafruit. Processing 3.0 - hardware-io. Onine-Quelle. https://learn.adafruit. com/processing-on-the-raspberry-pi-and-pitft/hardware-io, 2016.02.28. [ard 09] Arduino i2c bus speed. Online-Quelle. http://forum.arduino.cc/index.php?topic= 16793.0, 2016.02.29. [ard 16] Arducam homepage. Online-Quelle. http://www.arducam.com, 2016.02.29. [Audet 11] S Audet. Javacv. https://github.com/bytedeco/javacv. [Axis Corporation 08] Axis Corporation. Axis etrax fs - a 󰅮lexible multi-processor system-on- chip for network devices. Brochure. http://www.axis.com/files/datasheet/ds_etrax_fs_ 32179_en_0805_lo.pdf, 2016.02.26. [Barroso 05] Luiz André Barroso. The price of performance. Queue, 3(7):48–53, 2005. [Basetech 09] Basetech. Leistungsmesser, cost control 3000. Online-Quelle. http: //produktinfo.conrad.de/datenblaetter/125000-149999/125333-an-01-ml-Cost_Control_ 3000_de_en_nl.pdf, 2016.02.29. [Bautista Saiz 14] V. Bautista Saiz, F. Gallego. Gpu: Application for cctv systems. Tagungsband: Security Technology (ICCST), 2014 International Carnahan Conference on, Seiten 1–4, Oct 2014. [Bellard 12] Fabrice Bellard, M Niedermayer et al. Ffmpeg. Availabel from: http://ffmpeg. org, 2012. 87 [Blake 11] Joshua Blake et al. Openkinect. [Bradski 00] G. Bradski. Opencv. Dr. Dobb’s Journal of Software Tools, 2000. [Broadcom Europe Ltd 12] Broadcom Europe Ltd. Bcm2835 arm. Datenblatt. https: //www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2835/BCM2835-ARM- Peripherals.pdf, 2016.02.27. [Brodowski 13] Dominik Brodowski, Nico Golde. Linux cpufreq governors. Linux Kernel. https://www. kernel. org/doc/Documentation/cpu-freq/governors. txt, 2013. [Chianese 15] Angelo Chianese, Francesco Piccialli, Giuseppe Riccio. Designing a smart multi- sensor framework based on beaglebone black board. In Computer Science and its Applicati- ons, Seiten 391–397. Springer, 2015. [CircuitCo 14] CircuitCo. Circuitco: Audio cape revb. Online-Quelle. http://elinux.org/CircuitCo: Audio_Cape_RevB, 2016.02.28. [CircuitCo 16] CircuitCo. Circuitco: Beaglebone 3.1mp camera. Online-Quelle. http://elinux. org/CircuitCo:BeagleBone_3.1MP_Camera, 2016.02.27. [Coley 13] Gerald Coley. BeagleBone Black - System Reference Manual, rev a5.2 Auflage, 2013. https://www.adafruit.com/datasheets/BBB_SRM.pdf. [Compaq 00] Intel Compaq, Lucent Intel et al. Universal serial bus speci󰅮ication revision 2.0. Tagungsband: USB Implementersz Forum, 2000. [Cucchiara 00] Rita Cucchiara, Massimo Piccardi, Paola Mello. Image analysis and rule-based reasoning for a traf󰅮ic monitoring system. Intelligent Transportation Systems, IEEE Transac- tions on, 1(2):119–130, 2000. [Cutler 00] Ross Cutler, Larry S. Davis. Robust real-time periodic motion detection, analy- sis, and applications. Pattern Analysis and Machine Intelligence, IEEE Transactions on, 22(8):781–796, 2000. [Cyt 13] Cytron Technologies Sdn. Bhd. Product User’s Manual - HC-SR04 Ultrasonic Sensor, v 1.0 Auflage, 05 2013. [Demaagd 12] Kurt Demaagd, Anthony Oliver, Nathan Oostendorp, Katherine Scott. Practical 88 Computer Vision with SimpleCV: The Simple Way to Make Technology See. O’Reilly Media, Inc., 2012. [EEMBC 16] EEMBC. Eembc - industry-standard benchmarks for embedded systems. Online- Quelle. http://www.eembc.org, 2016.02.27. [elecfreaks.com 15] elecfreaks.com. Ultrasonic ranging module hc - sr04. Online-Quelle. http: //www.micropik.com/PDF/HCSR04.pdf, 2016.02.28. [Elphel, Inc. 15a] Elphel, Inc. Elphel 313 series cameras. Online-Quelle. http://www.elphel. com/model313/, 2015.04.18. [Elphel, Inc. 15b] Elphel, Inc. Elphel nc353l highly recon󰅮igureable camera. Brochure. http: //www3.elphel.com/sites/default/files/Elphel_353_Brochure_2010_V05.pdf, 2015.04.18. [Elphel, Inc. 15c] Elphel, Inc. Elphel nc353l series cameras. Online-Quelle. http://www3.elphel. com/model_353_cameras, 2015.04.18. [Felzenszwalb 10] Pedro F Felzenszwalb, Ross BGirshick, DavidMcAllester, DevaRamanan. Ob- ject detectionwith discriminatively trained part-basedmodels. PatternAnalysis andMachine Intelligence, IEEE Transactions on, 32(9):1627–1645, 2010. [g7smy.co.uk 13] g7smy.co.uk. Recording sound on the raspberry pi. Online-Quelle. http:// www.g7smy.co.uk/?p=283, 2016.02.28. [Gabrikowski 08] Jens Gabrikowski. User generated content am beispiel einer autonom arbei- tenden webcam. Master Thesis, 2008. [Herity 98] Dominic Herity. C++ in embedded systems: Myth and reality. Embedded Systems Programming, 11(2):48–71, 1998. [Hodges 06] Steve Hodges, Lyndsay Williams, Emma Berry, Shahram Izadi, James Srinivasan, Alex Butler, Gavin Smyth, Narinder Kapur, Ken Wood. UbiComp 2006: Ubiquitous Compu- ting: 8th International Conference, UbiComp2006Orange County, CA, USA, September 17-21, 2006Proceedings, Kapitel SenseCam: ARetrospectiveMemoryAid, Seiten 177–193. Springer Berlin Heidelberg, Berlin, Heidelberg, 2006. [Hughes 13] James Hughes. The raspberry pi camera - part 1. The MagPi - A Magazine for 89 Raspberry Pi Users. https://www.raspberrypi.org/magpi-issues/MagPi14.pdf, 2016.02.27. [Huppler 13] Karl R. Huppler. Selected Topics in Performance Evaluation and Benchmarking: 4th TPC Technology Conference, TPCTC 2012, Istanbul, Turkey, August 27, 2012, Revised Selected Papers, Kapitel Performance Per Watt - Benchmarking Ways to Get More for Less, Seiten 60–74. Springer Berlin Heidelberg, Berlin, Heidelberg, 2013. [IMC 16] IMC Viseum. IMC Intelligent Moving Camera CCTV, 2016. http://www.viseum.co.uk/ downloads/panoramic-security-camera.pdf. [Inc. 16] MathWorks Inc. Matlab - computer vision system toolbox. Online-Quelle. http://de. mathworks.com/products/computer-vision/, 2016.02.28. [Jackson 11] Mike Jackson, Steve Crouch, Rob Baxter. Software evaluation: criteria-based as- sessment. 2011. [Krizhevsky 12] Alex Krizhevsky, Ilya Sutskever, Geoffrey EHinton. Imagenet classi󰅮icationwith deep convolutional neural networks. Tagungsband: Advances in neural information proces- sing systems, Seiten 1097–1105, 2012. [Kruse 98] Eckhard Kruse, Friedrich M Wahl. Camera-based monitoring system for mobile robot guidance. Tagungsband: Intelligent Robots and Systems, 1998. Proceedings., 1998 IEEE/RSJ International Conference on, Band 2, Seiten 1248–1253. IEEE, 1998. [Lang 16] Jean-Philippe Lang. Cmucam5: Pixie homepage. Online-Quelle. http://www.cmucam. org/projects/cmucam5, 2016.02.29. [Le 13] Quoc V Le. Building high-level features using large scale unsupervised learning. Ta- gungsband: Acoustics, Speech and Signal Processing (ICASSP), 2013 IEEE International Con- ference on, Seiten 8595–8598. IEEE, 2013. [LeanXcam 08] Supercomputing Systems AG LeanXcam. Leanxcam. Online-Quelle. https:// github.com/scs/leanXcam/wiki, 2015.04.18. [LeanXcam 15] Supercomputing Systems AG LeanXcam. Leanxcam end-of-life status. Online-Quelle. https://www.scs.ch/fileadmin/images/leanXcam/EOL_Letter_leanXcam. pdf, 2015.03.19. 90 [Li 08] J. Li, W. Hao. Research and design of embedded network video monitoring system ba- sed on linux. Tagungsband: Computer Science and Software Engineering, 2008 International Conference on, Band 5, Seiten 1310–1313, Dec 2008. [Lieberman 05] Zachary Lieberman. openframeworks. Online-Quelle. http://openframeworks. cc/about/, 2016.02.28. [Liu 10] L. Liu. C-based/cached/core computer vision library, amodern computer vision library. Online-Quelle. http://libccv.org, 2016.02.28. [Mas 15] Massachusetts Institute of Technology. The MIT License (MIT), 2015. http:// opensource.org/licenses/MIT. [Matsugu 03] Masakazu Matsugu, Katsuhiko Mori, Yusuke Mitari, Yuji Kaneda. Subject inde- pendent facial expression recognitionwith robust face detection using a convolutional neural network. Neural Networks, 16(5):555–559, 2003. [Max 15] Maxim Integrated Products Inc., 120 San Gabriel Drive, Sunnyvale, CA 94086. DS1307 64 x 8, Serial, I2C Real-Time Clock, 2015. http://datasheets.maximintegrated.com/en/ds/ DS1307.pdf. [Moler 80] Cleve Moler et al. Matlab - user’s guide. Alberquerque, USA, 1980. [Noble 09] Joshua Noble. Programming Interactivity: A Designer’s Guide to Processing, Ardui- no, and Openframeworks. O’Reilly Media, Inc., 2009. [NVIDIA Corporation 16] NVIDIA Corporation. Jetson embedded platform. Online-Quelle. https://developer.nvidia.com/embedded-computing, 2016.02.27. [Nvidia 08] CUDA Nvidia. Programming guide. [Oxer 16] Jonathan Oxer. Arduino shield list. Online-Quelle. http://shieldlist.org, 2016.02.27. [Par 14] Parallax Inc. PIR Sensor (555-28027), v 2.3 Auflage, 03 2014. [Patterson 15] David Patterson. Arduino (mega) audio recording. Online-Quelle. http://www. instructables.com/id/Arduino-Mega-Audio-File-logging/, 2016.02.28. [pic 16] Raspberry pi, how much power does the camera module use? Online-Quelle. https: //www.raspberrypi.org/help/faqs/\#cameraPower, 2016.02.29. 91 [Poovey 09] Jason A Poovey, Markus Levy, Shay Gal-On, Thomas M Conte. A benchmark charac- terization of the eembc benchmark suite. IEEE Computer Society, 2009. [Prechelt 00] Lutz Prechelt. An empirical comparison of seven programming languages. Com- puter, 33(10):23–29, 2000. [Pul 15] PulsedLight Inc. LIDAR-Lite v2 Overview, 2015. https://cdn.sparkfun.com/ datasheets/Sensors/Proximity/lidarlite2DS.pdf. [Pulli 12] Kari Pulli, Anatoly Baksheev, Kirill Kornyakov, Victor Eruhimov. Realtime computer vision with opencv. Queue, 10(4):40:40–40:56, April 2012. [Qua 14] Qualcomm Technologies, Inc. FastCV SDK Release Notes, 2014. https://developer. qualcomm.com/qfile/27288/releasenotes.pdf. [Rajan 14] Ajitha Rajan, Subodh Sharma, Peter Schrammel, Daniel Kroening. Accelerated test execution using gpus. Tagungsband: Proceedings of the 29th ACM/IEEE international confe- rence on Automated software engineering, Seiten 97–102. ACM, 2014. [Roberts-Hoffman 09] Katie Roberts-Hoffman, Pawankumar Hegde. Arm cortex-a8 vs. intel atom: Architectural and benchmark comparisons. Dallas: University of Texas at Dallas, 2009. [Rowe 07] Anthony G Rowe, Adam Goode, Dhiraj Goel, Illah Nourbakhsh. Cmucam3: an open programmable embedded vision sensor. 2007. [Sasson 91] Steven J Sasson, Robert G Hills. Electronic still camera utilizing image compression and digital storage. US Patent 5,016,107. [Tex 13] Texas Instruments. OMAP3530 and OMAP3525 Applications Processors, 2013. http: //www.ti.com/lit/ds/symlink/omap3530.pdf. [Tex 94] Texas Instruments. TSL235 - Light to frequency converter, September 1994. http: //www.ti.com/lit/ds/symlink/tsl235.pdf. [Topliss 14] JamesWilliamTopliss, Victor Zappi, AndrewMcPherson et al. Latencyperformance for real-time audio on beaglebone black. 2014. [UBM Tech 14] UBM Tech. 2014 embedded market study. Online-Quelle. http://bd.eduweb. hhs.nl/es/2014-embedded-market-study-then-now-whats-next.pdf, 2016.02.28. 92 [Viola 01] Paul Viola, Michael Jones. Rapid object detection using a boosted cascade of simple features. Tagungsband: Computer Vision and Pattern Recognition, 2001. CVPR 2001. Procee- dings of the 2001 IEEE Computer Society Conference on, Band 1, Seiten I–511. IEEE, 2001. [Viola 04] Paul Viola, Michael J Jones. Robust real-time face detection. International journal of computer vision, 57(2):137–154, 2004. [viv 16] Vivanco universal-netzteil. Online-Quelle. http://www.vivanco.de/Startseite/ Produkte/Energie/Netzteile-und-Ladeadapter/Universal/vivanco-27822-universal- netzteil.html?id=nsession, 2016.02.29. [WaveRP 16] WaveRP. Waverp - arduino library for recording and playing wave 󰅮iles. https: //code.google.com/archive/p/waverp/, 2016.02.28. [Wikipedia 16] Wikipedia. Comparison of single-board computers. https://en.wikipedia.org/ wiki/Comparison_of_single-board_computers, 2016.02.27. [Wil 16] Wildlife Acoustics, Inc. Song Meter SM4 - Bioacoustics recorder, 2016. https://www. wildlifeacoustics.com/images/documentation/SM4-USER-GUIDE.pdf. [WIZ 08] WIZnet Co., Inc. W5100 Datasheet, version 1.1.6 Auflage, 2008. https://www. sparkfun.com/datasheets/DevTools/Arduino/W5100_Datasheet_v1_1_6.pdf. [Wol 14] Wolfson Microelectronics. Wolfson Audio Card User Documentation, 1 Auflage, 2014. https://www.element14.com/community/servlet/JiveServlet/downloadBody/65691- 102-4-292052/Wolfson%20Raspberry%20Pi%20Soundcard%20Manual%20_%20IMG% 20install_%20V1.2.pdf. [Zahn 14] Klaus Zahn, Mariana Reyes Peres. User documentation for leanXcam. Hochschule Luzern, v 1.00 Auflage, 09 2014. [Zeppelzauer 13] Matthias Zeppelzauer, Angela S Stöger, Christian Breiteneder. Acoustic detec- tion of elephant presence in noisy environments. Tagungsband: Proceedings of the 2nd ACM international workshop on Multimedia analysis for ecological data, Seiten 3–8. ACM, 2013. 93