68
Entwicklung einer intelligenten, selbstversorgenden Türüberwachung mit Hilfe von modernen Single-Board Computern von Hendrik Sören Erik Linka Erstprüfer: Prof. Dr. Karl Jonas Zweitprüfer: Prof. Dr. rer. nat. Clemens Hoffmann Studiengang: Bachelor Wirtschaftsinformatik Eingereicht am: 2. November 2015

Entwicklung einer intelligenten, selbstversorgenden ... · 3 Zusammenfassung Diese Abschlussarbeit behandelt die Entwicklung eines Türüberwachungsprototyps mit-hilfe moderner Single-Board-Computer

  • Upload
    others

  • View
    2

  • Download
    0

Embed Size (px)

Citation preview

Entwicklung einer intelligenten,selbstversorgenden Türüberwachungmit Hilfe von modernen Single-Board

Computern

von

Hendrik Sören Erik Linka

Erstprüfer: Prof. Dr. Karl JonasZweitprüfer: Prof. Dr. rer. nat. Clemens HoffmannStudiengang: Bachelor WirtschaftsinformatikEingereicht am: 2. November 2015

Persönliche Erklärung

Erklärung

Hiermit erkläre ich an Eides Statt, dass ich die vorliegende Arbeit selbst angefertigt habe;

die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche

kenntlich gemacht. Die Arbeit wurde bisher keiner Prüfungsbehörde vorgelegt und auch

noch nicht veröffentlicht.

Bonn, (2. November 2015)

(Hendrik Sören Erik Linka)

3

Zusammenfassung

Diese Abschlussarbeit behandelt die Entwicklung eines Türüberwachungsprototyps mit-

hilfe moderner Single-Board-Computer. Ziel ist es, älteren Menschen, deren Sinne und

Wahrnehmungsfähigkeiten beeinträchtigt sind, bei der Identifizierung der vor der Haus-

tür stehenden Personen zu helfen. Im Mittelpunkt der Betrachtung stehen dabei die The-

matik der unabhängigen Stromversorgung durch erneuerbare Energien und die der zu-

verlässigen Erkennung von Personen bei schlechten Sichtverhältnissen.

Vor dem Bau des Prototyps wurden deshalb sechs Anforderungen aufgestellt, die eine

sehr gute Kamera, eine unabhängige Stromversorgung durch erneuerbare Energien und

eine offene Funkschnittstelle voraussetzten. Anhand der Anforderungen konnten Priori-

täten gesetzt werden, um den Fokus auf ein schnelles und zugleich sparsames System zu

richten.

Die Entwicklung des mit einem Akku betriebenen Prototyps wurde mit dem Bau des Ka-

merasystems begonnen. Durch den sehr hohen Stromverbrauch konnte jedoch kein 24-

Stunden-Betrieb ermöglicht werden. Aus diesem Grund wurde in einem zweiten Schritt

ein Mikrocontroller, der das Kamerasystem nur bei Bedarf aktiviert, für die Steuerung

der Stromversorgung verbaut, um die Ressourcen der Batterie nicht zu vergeuden. Die-

ser nutzt einen Infrarotsensor zur Erkennung von Personen.

Ziel war es, durch den Einsatz erneuerbarer Energien und dem Senken des Stromver-

brauchs, eine Unabhängigkeit von externen Stromversorgungen zu erreichen. Hierzu

wurde neben dem Mikrocontroller eine Ladesteuerung installiert, die den Akku durch

die verfügbare Energie von Solarzellen auflädt.

Die Erkenntnis, die durch die Untersuchung in vorliegender Arbeit gewonnen werden

konnte, ist, dass der Raspberry Pi 2 und die angeschlossene Kamera in der Lage sind, in

unter zehn Sekunden zu booten und ein Full-HD-Stream mit 15 Bildern pro Sekunde an

einen Server zu schicken. Die Kombination aus leistungsstarken und energiesparenden

Single-Board-Computern ermöglicht es zudem, einen 24-Stunden-Betrieb durch einen

6000 mA Akku zu garantieren, der durch Sonnenkollektoren geladen wird. Als einziger

Nachteil stellte sich heraus, dass die Stromversorgung nur im Außenbereich oder direkt

am Fenster in ausreichender Weise durch Solarzellen sichergestellt werden konnte.

Inhaltsverzeichnis I

Inhaltsverzeichnis

Tabellenverzeichnis III

Abbildungsverzeichnis IV

Abkürzungsverzeichnis V

1. Einführung 11.1. Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2. Stand der Technik 3

3. Hardware Erläuterung 53.1. Raspberry Pi 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.2. Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.3. CSI-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4. Software Erläuterung 74.1. BuildRoot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74.2. Arduino IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

5. Entwurf einer technischen Umsetzung 85.1. Kamerasystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85.2. Energieverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85.3. Funkübertragung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95.4. Schaltplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

6. Entwicklung eines Türüberwachungsprototyps 116.1. Raspberry Pi 2 als Kamerasystem . . . . . . . . . . . . . . . . . . . . 11

6.1.1. Anschluss der Kamera . . . . . . . . . . . . . . . . . . . . . . 116.1.2. Auswahl und Anschluss der Funkschnittstelle . . . . . . . . . . 116.1.3. Anschluss des Displays . . . . . . . . . . . . . . . . . . . . . . 136.1.4. Entwicklung der Firmware . . . . . . . . . . . . . . . . . . . . 13

6.1.4.1. Installation . . . . . . . . . . . . . . . . . . . . . . . 146.1.4.2. Konfiguration des Systems . . . . . . . . . . . . . . 156.1.4.3. Test des Systems . . . . . . . . . . . . . . . . . . . . 196.1.4.4. Vergleich verschiedener Bildübertragungstechnologien 20

6.2. Bewegungssensoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.2.1. Pyroelektrischer Sensor . . . . . . . . . . . . . . . . . . . . . 266.2.2. Ultraschallsensor . . . . . . . . . . . . . . . . . . . . . . . . . 276.2.3. Radarsensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286.2.4. Reichweite der Sensoren . . . . . . . . . . . . . . . . . . . . . 30

II

6.2.5. Stromverbrauch der Sensoren . . . . . . . . . . . . . . . . . . 326.2.6. Ergebnis des Sensoren Vergleichs . . . . . . . . . . . . . . . . 33

6.3. Arduino Mikrocontroller . . . . . . . . . . . . . . . . . . . . . . . . . 336.3.1. Das Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.3.2. Raspberry Pi 2 Relais . . . . . . . . . . . . . . . . . . . . . . . 346.3.3. Entwicklung der Firmware . . . . . . . . . . . . . . . . . . . . 38

6.4. Planung und Ausführung der Stromversorgung . . . . . . . . . . . . . 426.4.1. Ladesteuerung . . . . . . . . . . . . . . . . . . . . . . . . . . 426.4.2. Sonnenkollektor . . . . . . . . . . . . . . . . . . . . . . . . . 446.4.3. Spannungswandler . . . . . . . . . . . . . . . . . . . . . . . . 44

6.5. Montage des Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7. Test des Systems 477.1. Reaktionszeit des Kamerasystems . . . . . . . . . . . . . . . . . . . . 477.2. Stromverbrauch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

7.2.1. Stromverbrauch des Raspberry Pi 2 . . . . . . . . . . . . . . . 487.2.2. Stromverbrauch des Arduino Mikrocontroller . . . . . . . . . . 487.2.3. Ergebnis der Strommessungen . . . . . . . . . . . . . . . . . . 48

7.3. Bildqualität in unterschiedlichen Lichtumgebungen . . . . . . . . . . . 497.3.1. Aufnahmen bei Tageslicht . . . . . . . . . . . . . . . . . . . . 497.3.2. Aufnahmen bei schwachem Licht . . . . . . . . . . . . . . . . 50

7.4. Überprüfung der Anforderungen . . . . . . . . . . . . . . . . . . . . . 517.4.1. Anforderung 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 517.4.2. Anforderung 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 517.4.3. Anforderung 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 517.4.4. Anforderung 4 . . . . . . . . . . . . . . . . . . . . . . . . . . 527.4.5. Anforderung 5 . . . . . . . . . . . . . . . . . . . . . . . . . . 527.4.6. Anforderung 6 . . . . . . . . . . . . . . . . . . . . . . . . . . 527.4.7. Ergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

8. Fazit 53

A. Anhang 59A.1. Vorder- und Rückseite des Prototyps . . . . . . . . . . . . . . . . . . . 59

Tabellenverzeichnis III

Tabellenverzeichnis

1. Verbrauch und Transferrate von bekannten WLAN-USB-Adaptern im

2,4 GHz Bereich [12] . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2. Testreichweite des Radarsensors . . . . . . . . . . . . . . . . . . . . . 31

3. Testreichweite des pyroelektrischen Sensors . . . . . . . . . . . . . . . 32

4. Stromverbrauchsmesswerte der Sensoren . . . . . . . . . . . . . . . . 32

5. Stromverbrauchsmesswerte des Raspberry Pi 2 . . . . . . . . . . . . . 48

6. Stromverbrauchsmesswerte des Arduino Mikrocontrollers . . . . . . . 48

Abbildungsverzeichnis IV

Abbildungsverzeichnis

1. Untersuchter Türspion . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Verbindungsmöglichkeiten des Raspberry Pi [6, S.4] . . . . . . . . . . 5

3. Schaltplan des Prototyps . . . . . . . . . . . . . . . . . . . . . . . . . 10

4. Aufbau und Messung des WLAN USB Stick Edimax EW-7811UN . . . 13

5. RPi-Buildroot Kernelkonfiguration . . . . . . . . . . . . . . . . . . . . 16

6. Latenztest von GStreamer . . . . . . . . . . . . . . . . . . . . . . . . . 24

7. Latenztest von Netcat . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

8. Beide Seiten des pyroelektrischen Sensors mit abgebauter Fresnel Linse 27

9. Ultraschallsensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

10. Beide Seiten des Radarsensors IPM-165 mit Vorverstärker . . . . . . . 30

11. Test der Sensorreichweite . . . . . . . . . . . . . . . . . . . . . . . . . 30

12. Optokopplerschaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

13. Restwelligkeit von CP07009(links) und XL6009(rechts) . . . . . . . . 45

14. Person bei Tageslicht . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

15. Person bei starkem Gegenlicht . . . . . . . . . . . . . . . . . . . . . . 50

16. Person bei künstlichem Licht . . . . . . . . . . . . . . . . . . . . . . . 50

17. Person bei vollkommener Dunkelheit . . . . . . . . . . . . . . . . . . . 51

18. Vorderseite des Prototyps . . . . . . . . . . . . . . . . . . . . . . . . . 59

19. Rückseite des Prototyps . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Abkürzungsverzeichnis V

API Application Programming Interface

AT Attention

CSI Camera Serial Interface

CW Continuous Wave

DSI Display Serial Interface

FTP File Transfer Protocol

GPIO General-purpose input/output

GPU Graphics Processing Unit

HD High Definition

HDMI High Definition Multimedia Interface

LiPo Lithium-Polymer-Akku

MDF Mitteldichte Holzfaserplatt

MPPT Max Power Point Tracking

NF Niederfrequenz

PWM Pulsweitenmodulation

SCP Secure Copy Protocol

SD-Karten Secure Digital Memory Card

SDRAM Synchronous Dynamic Random Access Memory

TTL Transistor-Transistor-Logik

UART Universal Asynchronous Receiver Transmitter

USB Universal Serial Bus

VGA Video Graphics Array

WLAN Wireless Local Area Network

Einführung 1

1. Einführung

Mit der rasanten Entwicklung der Digitalisierung, die mittlerweile unseren gesamten

Alltag erfasst hat, gewinnen elektronische Gegenstände immer mehr Bedeutung in un-

serem Leben. Ein Trend der letzten Jahre ist der Bereich der „Internet of Things“. [34]

Dabei handelt es sich um intelligente Systeme, die ihrem Nutzer helfen sollen, den Alltag

mit Hilfe von Technik zu bewältigen. Im Bereich der Türüberwachung gibt es zahlreiche

Lösungen, die sich unter dieser Kategorie einordnen lassen. Ein System, das in der Lage

ist, eine vor der Tür stehende Person zu identifizieren, wird jedoch noch von keinem

Unternehmen angeboten. Vor allem ältere Menschen, die sich nicht mehr voll auf ihre

Sinne verlassen können, würden von einem System profitieren, das sie darauf hinweist,

wer vor der Tür steht. Die dafür notwendigen Techniken wurden bereits entwickelt. So

ist es möglich, Kamerabilder zu analysieren und Gesichtsprofile zu erstellen, die dabei

helfen, Personen wiederzuerkennen. [28] Das System könnte dann zwischen bekannten

und unbekannten Personen unterscheiden.

1.1. Problemstellung

Ziel dieser Abschlussarbeit ist es, die Hardware eines Türüberwachungsprototyps mit

modernen Single-Board-Computern zu entwickeln. Die Grundlage der Realisierung ist

die spätere Nutzung im Heimautomatisierungsnetz von Prof. Dr. Karl Jonas. Die Kame-

ra wird dazu im Verbund mit einer noch zu entwickelnden Personenerkennungssoftware,

basierend auf OpenCV, eingesetzt. Da das gesamte System dem Bewohner dazu dienen

soll, Personen an der Tür zu identifizieren, werden speziell für diesen Fall folgende An-

forderungen an eine Haustürkamera gestellt:

1. eine High Definition (HD) Bildqualität der Kamera,

2. ein Kamerasystem, dass innerhalb von zehn Sekunden startet, um den Besucher

rechtzeitig zu identifizieren,

3. ein unabhängiges System ohne externe Kabel,

4. eine zuverlässige Bewegungserkennung, die Objekte schon aus weiter Entfernung

erkennt,

5. eine offene Funkschnittstellen zur Übertragung von Bildern,

6. gute Aufnahmen bei schwierigen Sichtverhältnissen.

Zur Lösung des Problems wurde die Arbeit in fünf Abschnitte eingeteilt. Zunächst er-

folgt eine Einführung in den Stand der Technik. Danach werden einige Grundbegriffe im

Bereich der Soft- und Hardware erklärt, die für das folgende Kapitel, dem Entwurf eines

Einführung 2

technischen Systems, notwendig sind. Daraufhin wird der Bau des eigentlichen Proto-

typs erläutert, indem der Aufbau, die dabei aufgetretenen Probleme und der Nutzen jeder

einzelnen Komponente im Fokus der Betrachtung stehen. Zum Schluss werden zahlrei-

che Tests durchgeführt, mit denen nachgewiesen werden kann, ob die oben genannten

Anforderungen erfüllt werden konnten.

Stand der Technik 3

2. Stand der Technik

Die Türüberwachungsanlagen der Industrie besitzen alle unterschiedliche Hardware-

komponenten, dieses werden aber immer im gleichen Wechselspiel miteinander verbaut.

Der Aufbau der Anlage beinhaltet drei Grundkomponenten: Es wird ein Prozessor einge-

baut, der den Großteil der Funktionen eines Systems übernimmt, auch System-on-a-Chip

genannt. Er bietet einen Anschluss für eine Kamera und kann die Verarbeitung der Daten

direkt übernehmen. Zur Bewegungserkennung wird ein Infrarotsensor genutzt, der die

Kamera auslöst, sobald er etwas erkennt.

Bis zu dieser Stelle gibt es bei den Systemen kaum Unterschiede. Die Bereiche, in denen

eine Differenzierung der Produkte festgestellt werden kann, liegen in der Interaktion mit

dem Anwender und der Auflösung der Kamera.

Bei der Interaktion bietet sich zum einen die Lösung an, dass über einen Bildschirm

direkt mit dem Anwender kommuniziert wird. Eine Voraussetzung wäre dabei aber, dass

sich der Anwender immer in der Nähe des Gerätes befinden müsste. Bei einer zweiten

Lösung verfügt die Anlage über eine Funkschnittstelle und die Kommunikation erfolgt

mit dem mobilen Endgerät des Anwenders. Das Display wird durch das mobile End-

gerät ersetzt und zwingt ihn nicht, sich in der Nähe der Tür aufzuhalten. Welche dieser

beiden Lösungen verwendet wird, hängt stark von der Differenzierungsstrategie des Un-

ternehmens ab. Aus diesem Grund lässt sich der Markt der Türüberwachungsprodukte

technologisch in zwei Kategorien einteilen. Die erste Kategorie besteht aus Produkten,

die versuchen, sich durch den Preis zu differenzieren. In diesem Fall wird billige Tech-

nologie verbaut, die schon Jahre im Einsatz ist. Innovationen gibt es hier nur selten zu

beobachten. Eine eigene vorgenommene Analyse eines derzeit preiswert verkauften Tür-

spions ergab, dass sich im Inneren ein umgebautes Smartphone befand, das den Stand

der Technik von 2011 nutzte und normalerweise über eine Funkschnittstelle verfügt, ent-

weder in Form von Wireless Local Area Network (WLAN), Bluetooth oder Mobilfunk.

Alle Bemühungen, diese Technik in ein intelligentes Gerät umzubauen, scheiterten auf-

grund fehlender Anschlüsse und Softwareupdates, die wahrscheinlich dem Preisdruck

zum Opfer fielen. So konnte zwar eine serielle Verbindung mit dem Modem des Ge-

rätes aufgebaut werden, bis auf einen Statusbefehl wurden jedoch alle Attention (AT)-

Befehle abgeschaltet oder hatten keine Wirkung mehr auf das System. Dabei verfügte

der Türspion bereits über eine zur Montage bereite, halbwegs nutzbare Video Graphics

Array (VGA)-Kamera mit Infrarotdiode, ein Display mit einem Benutzerinterface und

einen Bewegungssensor. Es fehlte nur eine Ladesteuerung, die Solarzellen unterstützt,

eine hochauflösende Kamera und eine offene Funkschnittstelle.

Stand der Technik 4

Abbildung 1: Untersuchter Türspion

Zur zweiten Kategorie gehören Produkte, die sich von ihrem Preis her eher an die

Enterprise-Nutzer richten. Vorreiter auf diesem Gebiet ist die Firma 1000eyes GmbH,

die seit 2013 den Business-to-Business-Sektor versorgt. Seit 2015 bieten sie auch eine

Lösung namens DoorBird für Privatkunden an, die sich auf dem „Stand der Technik“

befindet. Die Anlage wird mit dem Slogan „Meistverkaufte W-LAN Videotürklingel in

Europa“ verkauft. [26]

Der Vorteil des DoorBird-Systems ist die Stromversorgung über den Klingeldraht. Es

verfügt zudem über ein Alarmsystem, das bei Bewegung eine Nachricht oder ein Bild an

das mobile Endgerät des Anwenders schickt. Zur Aufnahme von Bildern, ist es zusätz-

lich mit einer HD-Kamera ausgerüstet, die durch Infrarot-LEDs auch nachts Personen

erkennen kann. Damit erfüllt sie zwar viele der notwendigen Anforderungen, sie be-

sitzt jedoch weder eine unabhängige Stromversorgung noch eine offene Schnittstelle.

Nur große Software-Unternehmen haben Zugriff auf die Application Programming In-

terface (API) der Firmware. [21] Entwickler ohne Industriekontakte können somit nicht

auf die Bilder des Systems zugreifen.

Hardware Erläuterung 5

3. Hardware Erläuterung

In folgendem Kapitel werden die wichtigsten Grundbegriffe der Hardware erläutert, da

diese zum Verständnis der Thematik in den darauf folgenden Kapiteln notwendig sind.

3.1. Raspberry Pi 2

Der Raspberry Pi wurde 2012 als Single-Board-Computer von der Raspberry Pi Foun-

dation vorgestellt. Er sollte der Nachfolger des aus den achtziger Jahren bekannten BBC

Micro werden, der ebenfalls für Lernzwecke vorgesehen war. Hauptziel der Raspberry

Pi Foundation war es dabei nicht, einen Computer auf den Markt zu bringen, der einen

maximalen Profit generiert. [6, S.2] Vielmehr sollte er viel Leistung für so wenig Geld

wie möglich bieten, damit er auch für einkommensschwächere Länder erschwinglich

sein konnte. Mit über drei Millionen verkauften Einheiten ist der Raspberry Pi wohl

der erfolgreichste Open-Source-Computer, was nicht zuletzt auf seine vielseitigen Ein-

satzmöglichkeiten, seinen Preis und sein Open-Source-Prinzip zurückzuführen ist. [6,

S.4] Im Frühjahr 2015 wurde der mit Spannung erwartete Nachfolger vorgestellt. Der

Raspberry Pi 2 besitzt nun einen schnelleren Prozessor und mehr Arbeitsspeicher.

Abbildung 2: Verbindungsmöglichkeiten des Raspberry Pi [6, S.4]

Der Rest des Boards wurde hingegen nur leicht verändert, um die Abwärtskompatibilität

vieler schon entwickelter Anwendungen und Erweiterungen nicht zu gefährden. Somit

besitzt er weiterhin einen Secure Digital Memory Card (SD-Karten)-Slot, jedoch jetzt

Hardware Erläuterung 6

im Micro-SD Format, vier Universal Serial Bus (USB) 2.0 und einen 100 MBit/s Ether-

netport, einen High Definition Multimedia Interface (HDMI)-Ausgang, einen Camera

Serial Interface (CSI)-Port für Kameras, einen Display Serial Interface (DSI)-Port für

Displays, einen kombinierten analogen Video- und Tonausgang und 40 General-purpose

input/output (GPIO) Stifte. [59]

3.2. Arduino

Bei einem Arduino handelt es sich um einen Mikroprozessor mit analogen und digitalen

Ein- und Ausgängen, der aufgrund seiner Open-Source-Lizenzierung große Beliebtheit

in der Prototypentwicklung erlangt hat. Er wurde erstmals im Jahr 2005 mit dem Ziel

vorgestellt, einen einfachen Umgang mit Hard- und Software für jedermann zu gewähr-

leisten. [3, S.51] Mittlerweile gibt es zahlreiche Varianten des Arduino in unterschiedli-

chen Größen. Viele von ihnen sind außerhalb der USA nur unter dem Namen Genduino

bekannt. [31] Da der Name Arduino dennoch weiterhin am weitesten im Internet ver-

breitet ist, wird er auch in den folgenden Kapiteln verwendet.

3.3. CSI-Schnittstelle

Die CSI-Schnittstelle wurde entwickelt, um der Industrie der Smartphone-Hersteller

einen Standard für die Verbindung zwischen Prozessor und Kamera zu geben. Die Her-

steller haben somit die Möglichkeit, dieselbe Kamera für verschiedene Prozessoren zu

verwenden. In der Open-Source-Community ist dieser Standard bisher leider nicht an-

gekommen. Der Raspberry Pi unterstützt trotz CSI-Schnittstelle nur eine speziell ent-

wickelte Kamera. Dies liegt vor allem an der schwierigen Ansteuerung von Kame-

ras. [15]

Software Erläuterung 7

4. Software Erläuterung

In diesem Kapitel stehen die Grundbegriffe der Software im Fokus der Betrachtung. Die

folgenden Erläuterungen sollen dazu beitragen, dass im weiteren Verlauf dieser Arbeit

das technische Grundverständnis dazu verhilft, einen besseren Einblick in den Aufbau

des vorgestellten Prototyps zu bekommen.

4.1. BuildRoot

Buildroot ist ein Systembuilder, der sämtliche Systemteile, wie z. B. den Kernel, gene-

riert. [53] Er bietet eine Art Standardisierung für die Kompilierung von Programmen an,

die auf einem anderen System mit einer anderen Architektur laufen sollen. Diesen Pro-

zess nennt man auch Cross-Compiling. Dafür stellt das Programm von sich aus sämt-

liche benötigten Werkzeuge zur Verfügung. Der Benutzer braucht nur die Architektur

des Zielsystems auszuwählen, und sofern diese vorhanden ist, wird dann ein auf seine

Bedürfnisse zugeschnittenes System erstellt.

4.2. Arduino IDE

Die Arduino IDE ist die offizielle Entwicklungsumgebung des Arduino Mikroprozes-

sors. Sie ermöglicht die Entwicklung von Software in einer einfach zu erlernenden Spra-

che, die C sehr ähnelt. Es gibt dafür die zwei Grundfunktionen „setup()“ und „loop()“.

Die eine Funktion wird beim Starten des Prozessors ausgeführt, die andere wiederholt

sich permanent. Programme, die in der IDE entwickelt wurden, können in so genannte

Sketches kompiliert und hochgeladen werden. [3, S.51]

Entwurf einer technischen Umsetzung 8

5. Entwurf einer technischen Umsetzung

Der technische Entwurf wurde auf Grundlage der in der Problemstellung aufgestellten

Anforderungen erstellt und dient bei der Entwicklung als Vorlage für die Umsetzung.

Dafür wurde jede Anforderung genauestens betrachtet und eine mögliche Lösung ge-

funden. Anschließend wurden die ausgewählten Komponenten in einem Schaltplan ge-

zeichnet.

5.1. Kamerasystem

Soll die erste Anforderung erfüllt werden, ist eine Kamera notwendig, die hochauflö-

sende Bilder machen kann. Dies konnte durch die Wahl einer geeigneten Basisplattform

gelöst werden. Die Wahl fiel auf den Raspberry Pi 2, der, wie schon erwähnt, im Früh-

jahr 2015 auf den Markt gebracht wurde. [59] Er besitzt mit seiner CSI-Schnittstelle

eine optimale Anbindung an eine performante Kamera, die, wie später auch gezeigt

wird, hochauflösende Bilder in jeder Lichtumgebung machen kann. Somit ist auch die

sechste Anforderung, die Aufnahme bei schwierigen Sichtverhältnissen, erfüllt. Ande-

re Open-Source-Plattformen besitzen momentan keine vergleichbare Kamera mit einem

fünf Megapixel Sensor und wurden deshalb nicht mit berücksichtigt. Zusätzlich bietet

die Raspberry Pi 2 Plattform momentan den besten Support und wird stetig weiterent-

wickelt. [6, S.6]

Eine Herausforderung stellt indes die zweite Anforderung dar, denn der Raspberry Pi

ist nicht gerade bekannt für einen schnellen Bootvorgang seiner Standarddistributionen

Raspian und Noobs. [59] Ziel ist es, den Raspberry Pi wirklich nur dann zu starten, wenn

eine Personenidentifizierung benötigt wird. Es muss deshalb ein kleines System kompi-

liert werden, das nur das Nötigste beinhaltet und damit möglichst schnell booten kann,

um ein Bild von der Person, die vor der Tür steht, zum Server zu schicken, bevor diese

wieder außer Sichtweite ist. Das Programm Buildroot könnte diese Aufgabe überneh-

men, da es ein maßgeschneidertes System für den Raspberry Pi erstellt. Durch das sehr

kleine System kann relativ schnell gestartet werden.

5.2. Energieverwaltung

Ein weiteres Problem ist der vergleichsweise hohe Stromverbrauch, der die Erfüllung der

dritten Anforderung, ein unabhängiges System ohne externe Kabel, z. B. eine Stromver-

sorgung, schwierig macht. Der Raspberry Pi 2 verbraucht sehr viel Strom und wird des-

halb nur angeschaltet, wenn er tatsächlich gebraucht wird. Die Aufgabe, den Raspberry

Pi 2 einzuschalten, übernimmt ein Arduino Mikrocontroller, der trotz seines nur 8 bis

Entwurf einer technischen Umsetzung 9

16 MHz schnellen Prozessors über genug Rechenleistung verfügt, um einfache bis kom-

plexe Bewegungssensoren anzusteuern. Diese Sensoren ermöglichen eine genaue Bewe-

gungserkennung und erfüllen damit die vierte Kernanforderung. Zudem verbraucht der

Mikroprozessor nur einen Bruchteil dessen, was ein Raspberry Pi in dieser Zeit benöti-

gen würde. Somit könnte das System theoretisch den ganzen Tag betrieben werden.

Damit das System auch tatsächlich unabhängig von anderen Stromversorgungen agieren

kann, werden Sonnenkollektoren verbaut, die den Lithium-Ionen-Akku tagsüber aufla-

den.

5.3. Funkübertragung

Für Anforderung fünf muss eine Funkanbindung an den Raspberry Pi angeschlossen

werden, um Bilder von der Kamera zum Server zu schicken. Da diese Anbindung eben-

falls Strom verbraucht, sollte sie mit einem sehr sparsamen Adapter stattfinden. Ein Test

verschiedener WLAN-Adapter muss insofern durchgeführt werden.

5.4. Schaltplan

Das komplett entwickelte System wird im Anschluss an die Entwicklung auf einer Mitteldichte

Holzfaserplatt (MDF)-Platte befestigt, um es für Tests transportierbar zu machen. Daher

wurde im Schaltplan des technischen Entwurfs ein Layout gewählt, das nicht zu viele

Komponenten übereinander stapelt. Zu sehen sind ebenfalls schon eingezeichnete Span-

nungswandler. Deren Aufgabe wird während der Entwicklung weiter erläutert.

Entwurf einer technischen Umsetzung 10

Abbildung 3: Schaltplan des Prototyps

Entwicklung eines Türüberwachungsprototyps 11

6. Entwicklung eines Türüberwachungsprototyps

Die nachfolgenden Kapitel beschäftigen sich mit der Umsetzung. Sie sind in einzelne lo-

gische Abschnitte des Entwicklungsprozesses aufgeteilt, damit dieser Prozess verständ-

lich nachvollzogen werden kann.

6.1. Raspberry Pi 2 als Kamerasystem

Zu Beginn wird sich mit der Aufnahme des Bildes mit einem geeigneten Single-Board-

Computer beschäftigt. Wie schon im vorangegangenen Kapitel erläutert, wurde hierzu

der Raspberry Pi 2 ausgewählt. In einem ersten Schritt müssen alle Komponenten an den

Raspberry Pi 2 angeschlossen werden, um eine geeignete Testumgebung herzustellen.

6.1.1. Anschluss der Kamera

Als Erstes wird die Kamera an den Raspberry Pi 2 angeschlossen. Die CSI-Kamera der

Raspberry Pi Foundation stellt eine Erweiterung des Raspberry Pi und Raspberry Pi 2

dar. Sie sticht im Vergleich zu anderen Lösungen, wie z. B. seriellen Kameras, aus der

Menge heraus. Kaum ein Produkt bietet eine Auflösung von maximal 2592 mal 1944 Pi-

xel bei fünf Megapixeln. Zudem ist sie mit ihren Maßen von 25 x 20 x 9 mm recht klein

und kann gut in kleinere Systeme integriert werden. Die Raspberry Foundation bietet die

Kamera auch ohne Infrarotfilter an. Dadurch können Bilder bei Dunkelheit mit Infrarot-

licht gemacht werden. [25] Zwei Infrarotleuchtdioden, die durch den 3,3 V Anschluss

des Raspberry Pi 2 versorgt werden, unterstützen die Kamera in der Nacht.

Die Infrarotkamera wird mithilfe eines Flachbandkabels in den CSI-Port des Raspberry

Pi 2 gesteckt. Dabei muss darauf geachtet werden, dass die Kontakte richtig herum im

CSI-Port stecken.

6.1.2. Auswahl und Anschluss der Funkschnittstelle

Der Raspberry Pi 2 verfügt über keine eigene Funkschnittstelle. Die einzigen nutzbaren

Netzwerkschnittstellen sind ein RJ45-Port und die nutzbaren GPIO Stifte. Da die Daten-

übertragung über Funk realisiert werden soll, fallen diese Möglichkeiten weg.

Die meist verwendeten Funkübertragungstechnologien, die der Raspberry Pi 2 zusätzlich

durch seine USB-Ports unterstützt, sind WLAN und Bluetooth. WLAN ist eine ausge-

reifte Technologie und wird von vielen Geräten unterstützt. Sie funkt im Bereich von 2.4

Entwicklung eines Türüberwachungsprototyps 12

GHz und 5 GHz. Die Stromaufnahme ist aber im Vergleich zu Bluetooth relativ hoch.

Dennoch wird in diesem Projekt noch kein Bluetooth verwendet, da der Standard relativ

jung ist und damit noch nicht viele Geräte unterstützt werden. [10] WLAN ist hingegen

relativ weit verbreitet und bietet über WLAN-Router eine einfache Möglichkeit, ein Si-

gnal an verschiedene Geräte, vom Smartphone über das Tablet bis hin zum Fernseher, zu

versenden. Somit kann das System in einem relativ großen Bereich der Wohnung viele

andere Geräte kontaktieren, die WLAN nutzen, um z. B. ins Internet zu gelangen.

Der Anschluss eines WLAN-USB-Adapters ist aufgrund der freien USB-Ports relativ

einfach, die Auswahl des richtigen Adapters ist es hingegen nicht. Der Adapter sollte

bei einer guten Datenübertragungsrate so wenig Strom wie nur möglich verbrauchen.

Ein Stream in Full HD braucht eine Übertragungsrate von 15,2 MBit/s. Der Blog Po-

werPi hat sich deshalb schon mit dieser Frage beschäftigt und eine Übersicht über die

bekanntesten WLAN-USB-Adapter erstellt. [12]

Tabelle 1: Verbrauch und Transferrate von bekannten WLAN-USB-Adaptern im 2,4 GHz Be-reich [12]

Produkt Stromverbrauch TransferrateEdimax EW-7612UAn (v2) 0,8 Watt 99,5 Mbit/sTP-Link WN822N (v3) 0,7 Watt 85,6 Mbit/sEdimax EW-7811UAC 0,6 Watt 73,4 Mbit/sTP-Link WN722N 0,9 Watt 70,5 Mbit/sEdimax EW-7811UN 0,5 Watt 60,2 Mbit/sTP-Link WN823N 0,8 Watt 58,2 Mbit/sD-Link DWA-140 1,0 Watt 25,7 Mbit/s

Wenn auch die Datenübertragung von 58,2 MBit/s nur im Mittelfeld der getesteten Ad-

apter liegt, verbraucht der Edimax EW-7811UN mit 0,5 Watt am wenigsten Strom. Eine

Überprüfung der Messwerte wurde zur Sicherheit durchgeführt. Dafür war es notwen-

dig, die Adern eines kurzen USB-Verlängerungskabels von der Isolierung freizulegen

und das rote Kabel durchzutrennen. Die Messspitzen des Messgerätes wurden dann an

die jetzt frei liegenden Enden des roten Kabels geklemmt, um den durchfließenden Strom

zu messen. Hierbei wird ein professionell geeichtes Messgerät der Marke Rigol einge-

setzt.

Entwicklung eines Türüberwachungsprototyps 13

Abbildung 4: Aufbau und Messung des WLAN USB Stick Edimax EW-7811UN

Beim Test konnte ein maximaler Wert von 99,375 mA bei 5,05 V ± 0.01 V festgestellt

werden. Das heißt, es wurden circa 0,502 Watt verbraucht. Damit stimmen die Messer-

gebnisse mit den Werten des Blogs überein.

6.1.3. Anschluss des Displays

Zu guter Letzt wird noch ein fünf Zoll großes Display angeschlossen, das während der

Testphase Informationen über den aktuellen Status des Systems angibt. Es ist speziell

für den Raspberry Pi 2 konzipiert und wird direkt auf die 40 Stifte gesteckt. Zudem

verbindet eine HDMI-Brücke das Display mit dem Board. Die HDMI-Brücke erlaubt es,

ein höher aufgelöstes Bild von 800 x 600 Pixel zu übertragen, als es mit dem GPIO-Port

möglich wäre. [18] Außerdem vereinfacht dieser Verbund die Montage des Raspberry Pi

2 auf einer MDF-Platte, da jeweils das Board und das Display auf einer Seite montiert

werden können. Es befindet sich für den späteren Betrieb ein Kippschalter am Display,

der dieses vollständig abschaltet und den Stromverbrauch damit verringert.

6.1.4. Entwicklung der Firmware

Ziel der Firmware ist es, möglichst schnell zu booten. Hierzu ist es notwendig, sich

den Bootvorgang näher anzusehen. Der Raspberry Pi 2 lädt das System in sechs Schrit-

ten. Zunächst wird in Schritt eins nur die Graphics Processing Unit (GPU) aktiviert, die

die Aufgabe hat, den ROM-Code zu starten. Dieser Code ist verantwortlich für die In-

itialisierung der SD-Karte. Danach wird in Schritt zwei nach einer Datei bootcode.bin

auf der SD-Karte gesucht, die wiederum den Synchronous Dynamic Random Access

Memory (SDRAM) aktivieren kann und die Datei „loader.bin“ im Schritt drei von der

SD-Karte in den SDRAM lädt. Ebenfalls wird im vierten Schritt noch die Firmware

„start.elf“ mit in den SDRAM geladen. In der Folge können jetzt in den letzten beiden

Schritten der Kernel und dessen Konfigurationsdateien gestartet werden. [6]

Entwicklung eines Türüberwachungsprototyps 14

Verändern lassen sich beim Booten nur die letzten drei Schritte, da es bisher keinen

Ansatz für eine Veränderung der GPU-Firmware gibt. Aus diesem Grund wird versucht

eine Verbesserung der Bootzeit durch die Verkleinerung des Kernels zu erreichen. Dazu

wird keine Standardlösung wie Raspian oder Noobs benutzt. Diese bieten zwar einen

leichten Einstieg, bringen aber auch viele nicht benötigte Features mit, die das Sys-

tem nur verlangsamen. Buildroot bietet hingegen die Möglichkeit, ein System innerhalb

von wenigen Sekunden zu booten. Raspian braucht zum Vergleich mindestens 25 Se-

kunden. [59] Der Aufbau der WLAN-Verbindung und das Starten der Kamera kommen

dabei noch hinzu.

Wie schon in den Erläuterungen zur Software erwähnt, besitzt Buildroot ein Baukas-

tenprinzip, mit dem jedes einzelne Teil des Systems selbst konfiguriert werden kann.

Damit wird das System auch nur mit den Features bestückt, die unbedingt benötigt wer-

den.

Der Bau eines Systems für den Raspberry Pi 2 mittels Buildroot wird schon länger

von der Community praktiziert. Durch die weite Verbreitung des Raspberry Pi 2 wur-

de infolgedessen ein weiteres Hilfsprogramm erstellt, das schon wichtige Einstellungen

wie die Architektur oder das Filesystem speziell für das Board vorgibt und bestimm-

te Einstellungen optimiert. Das ist vor allem vorteilhaft, da Buildroot für viele andere

Single-Board-Computer eine Unmenge an Einstellmöglichkeiten hat. Dieses Werkzeug

vereinfacht die Konfiguration immens, indem es nicht relevante Bereiche herausnimmt

und einen besseren Gesamtüberblick bietet. Es nennt sich RPI-Buildroot und wird von

Guillermo A. Amaral auf GitHub verwaltet. Das Projekt wird wie folgt beschrieben:

„This buildroot overlay will produce a bleeding-edge, light-weight and trimmed down

toolchain, rootfs and kernel for the Raspberry Pi. It’s intended for advanced users and

specific embedded applications.“ [2] Dieses Buildroot-Overlay nutzt selbst das Origi-

nal Buildroot als Quelle. Der Vorteil gegenüber dem ursprünglichen Buildroot ist, dass

320 Personen speziell an der Optimierung und der Stabilität des Raspberry Pi Systems

arbeiten.

6.1.4.1. Installation Die Installation von RPi-Buildroot funktioniert am besten auf

einem Linux basierten Betriebssystem. In diesem Projekt wird dazu Linux Mint ver-

wendet. Bevor man beginnen kann, müssen das Paket build-essential und das Paket

libncurses5-dev noch mit folgendem Befehl installiert werden. Hierzu wird ein Terminal

aufgerufen und folgender Befehl ausgeführt:

Quellcode 1: Installieren von build-essential

Entwicklung eines Türüberwachungsprototyps 15

sudo ap t−g e t i n s t a l l b u i l d−e s s e n t i a l l i b n c u r s e s 5 −dev

Build-essential enthält die notwendigen Compiler für C und C++ und unterstützt außer-

dem noch Makefiles. [30] Makefiles definieren dabei Regeln und Abhängigkeiten für

den Compiler. [13] Ncurses hingegen ist ein Werkzeug für die Bildschirmausgabe in

Terminals [63] und wird zum Anzeigen der Terminalmenüs von Buildroot benötigt. Je

nach Linux Distribution kann es vorkommen, dass noch weitere Pakete benötigt werden.

Sobald das Paket installiert wurde, kann RPi-Buildroot heruntergeladen und das ent-

standene Verzeichnis geöffnet werden.

Quellcode 2: Download von RPi-Buildroot [2]g i t c l o n e −−d e p t h 1 g i t : / / g i t h u b . com / gamara l / r p i−b u i l d r o o t . g i tcd r p i−b u i l d r o o t

Bevor das System konfiguriert wird, werden vorher noch die Standardeinstellungen für

den Raspberry Pi 2 gesetzt.

Quellcode 3: Setzen der Standardwerte für Buildroot [2]make r a s p b e r r y p i 2 _ d e f c o n f i g

6.1.4.2. Konfiguration des Systems Im Anschluss an die Installation kann der

Kernel konfiguriert werden. Aufgrund der großen Anzahl von Einstellungsmöglichkei-

ten bedarf es jedoch etwas Einarbeitungszeit, bis man sich bei der Konfiguration zurecht-

findet. Aus diesem Grund wird im Kernel nur der WLAN-Treiber ausgewählt. Änderun-

gen in anderen Bereichen können schnell zur Instabilität des Systems führen, sodass es

wichtig ist, genau zu wissen, welche Einstellungen man gerade verändert und welche

Auswirkungen sie haben.

Das Konfigurationsmenü wird mit dem Befehl gestartet:

Quellcode 4: Konfigurieren des Linux Kernel [2]make l i n u x−menuconf ig

Entwicklung eines Türüberwachungsprototyps 16

Abbildung 5: RPi-Buildroot Kernelkonfiguration

Es öffnet sich ein Menü innerhalb des Terminals. Zur Orientierung, an welcher Stelle

man sich gerade befindet, wird der aktuelle Pfad immer in der zweiten Zeile des Menüs

angezeigt. Um beispielsweise den WLAN-Treiber zu aktivieren, erfolgt zuerst die Öff-

nung von „Device Drivers > Network device support > Wireless LAN“ mithilfe der

Tastatur. An dieser Stelle sollte eine Liste aller verfügbaren Treiber zu sehen sein. Ob

diese Treiber eingebunden sind, erkennt man an den eckigen Klammern, die vor jedem

Menüeintrag stehen. „<Y>“ bedeutet: Das Modul wird in den Kernel eingebunden und

geladen. „<M>“ hingegen kopiert nur den Treiber mit ins System, lädt ihn aber nicht

standardmäßig in den Kernel. Wenn das Feld leer ist, wird das Modul nicht weiter be-

achtet. Um den richtigen Treiber auszuwählen, muss vorab der Chipsatz des Adapters

herausgefunden werden. Der ausgewählte WLAN-USB-Adapter Edimax EW-7811UN

verwendet einen Realtek RTL8188/92cu Chipsatz. [57] Dieser Chipsatz wird von dem

Treiber Realtek 8192c USB WiFi unterstützt. [9] Ein Blick in die Liste ergab, dass der

Treiber bereits mit „<M>“ markiert ist. Beim Versuch, diesen gleichzeitig mit in den

Kernel zu laden, gibt es eine Fehlermeldung, die aufgrund von Abhängigkeiten anderer

Module mit diesem Treiber das direkte Laden verhindert. Das heißt im Umkehrschluss,

dass in einem Bootskript, das später erstellt wird, der Befehl modprobe ausgeführt wer-

den muss. Dieser Befehl lädt Module während des Betriebs in den Kernel und aktiviert

diese. [36]

Im Anschluss an die Kernelkonfiguration müssen jetzt noch die notwendigen Pakete

für den WLAN-Betrieb und die Kamera ausgewählt werden. Dazu wird einer der beiden

folgenden Befehle ausgeführt:

Quellcode 5: Auswahlmenü der Pakete für das System [2]make menuconf igmake x c o n f i g

Entwicklung eines Türüberwachungsprototyps 17

Der erste Befehl öffnet ein Menü, das genauso aussieht und agiert wie das Terminalker-

nelkonfigurationsmenü. Der zweite Befehl startet hingegen eine grafische Oberfläche,

die auch die Nutzung der Maus erlaubt und die Bedienung etwas erleichtert. Damit dies

funktioniert, muss jedoch zuvor die Grafikbibliothek QT installiert werden.

In dem jetzt dargestellten Menü werden die verschiedenen Pakete gelistet, die zur Lauf-

zeit bereit stehen. Zuerst sollten die Pakete selektiert werden, die den WLAN-Betrieb

verwalten und steuern. Hierzu navigiert man zu „Target Packages“ und öffnet die „Net-

working applications“. Die nachfolgenden Pakete müssen mit einem „<Y>“ versehen

sein. Falls dem nicht so ist, sollten diese manuell mit der y-Taste hinzugefügt wer-

den. Das Paket „wpa_supplicant“ kümmert sich dabei um den Aufbau der WLAN-

Verbindung.

Quellcode 6: Auszuwählende Netzwerkpakete [9]T a r g e t p a c k a g e s / Networking a p p l i c a t i o n s / w i r e l e s s t o o l sT a r g e t p a c k a g e s / Networking a p p l i c a t i o n s / w p a _ s u p p l i c a n tT a r g e t p a c k a g e s / Networking a p p l i c a t i o n s / w p a _ s u p p l i c a n t / Enab le EAPT a r g e t p a c k a g e s / Networking a p p l i c a t i o n s / w p a _ s u p p l i c a n t / Enab le s y s l o g s u p p o r tT a r g e t p a c k a g e s / Networking a p p l i c a t i o n s / w p a _ s u p p l i c a n t / I n s t a l l w p a _ c l i b i n a r yT a r g e t p a c k a g e s / Networking a p p l i c a t i o n s / w p a _ s u p p l i c a n t / I n s t a l l w p a _ p a s s p h r a s e b i n a r y

Anschließend wird die Raspberry Pi 2 Firmware, die unter anderem den Betrieb der

Kamera ermöglicht, selektiert. Dafür navigiert man unter „Target Packages“ zu „Hard-

ware handling“. Dort kann „rpi-userland“ und „rpi-firmware“ ausgewählt werden. „rpi-

firmware“ befindet sich dabei unter einem weiteren Unterpunkt, der sich „Firmware“

nennt. Nach der Auswahl von „rpi-firmware“ erscheint noch ein weiterer Unterpunkt na-

mens „Firmware to boot“. In diesem muss der Punkt „extended“ ausgewählt werden.

Quellcode 7: Auszuwählende Raspberry Pi 2PaketeT a r g e t p a c k a g e s / Hardware h a n d l i n g / r p i−u s e r l a n dT a r g e t p a c k a g e s / Hardware h a n d l i n g / Firmware / r p i−f i r m w a r e / Firmware t o boo t / e x t e n d e d

Bevor man sich weiter mit der Konfiguration beschäftigt, kann ein erster Test durchge-

führt werden, um die vorherigen Einstellungen zu überprüfen. Hierzu werden die Ein-

stellungen gespeichert und das Menü verlassen. Anschließend wird mit dem Befehl „ma-

ke“ die Kompilierung gestartet:

Quellcode 8: Befehl zum Starten der Kompilierungmake

Die Kompilierung dauert etwa eine Stunde, je nach Internetverbindung und Rechenleis-

tung. In dieser Zeit werden die Pakete heruntergeladen, entpackt und für die gesetzte

Architektur übersetzt. Aus diesem Grund sollte vermieden werden, den Rechner oder

die Internetleitung stark zu belasten, da ansonsten ein Abbruch erfolgen kann und der

Prozess neu gestartet werden muss.

Entwicklung eines Türüberwachungsprototyps 18

Nach dem Abschluss der Kompilierung kann der erste Test durchgeführt werden. Es

wird dazu eine schnelle MicroSD-Karte benötigt. Diese sollte im PC stecken, die Parti-

tionen aber nicht gemountet sein. Werden die Partitionen automatisch gemountet, kann

der Befehl „umount“ dies zurücksetzen.

RPi-Buildroot bietet speziell für die Partitionierung und den Kopiervorgang ein eigenes

Skript an. Es wird mit folgendem Befehl gestartet:

Quellcode 9: Befehl zum Starten des RPi-Buildroot Skript [2]sudo boa rd / r a s p b e r r y p i 2 / mksdcard / dev / sdx

Das „x“ in „sdx“ muss durch den richtigen Buchstaben der SD-Karte ersetzt werden.

Sobald das Skript fertig ist, werden die beiden Partition „boot“ und „rootfs“ gemoun-

tet. In „boot“ legt man eine Datei mit dem Namen „config.txt“ mit folgendem Inhalt

an:

Quellcode 10: Inhalt von config.txt [56]gpu_mem_1024=512

Der für die GPU verfügbare Speicher wird damit auf 512 MB erhöht. Für spätere Video-

aufnahmen ist diese Einstellung essenziell, da es die Aufnahme von hoch aufgelösten

Bildern erlaubt. Diese verbrauchen mehr Arbeitsspeicher als normale Bildaufnahmen.

Als Nächstes wird das WLAN konfiguriert. Dazu wird die Partition „rootfs“ geöffnet

und die Datei „wpa_supplicant.conf“ mit Root-Rechten editiert. Es muss dazu eine Kon-

figuration für das WLAN-Netzwerk erstellt werden. Der Befehl „wpa_passphrase ssid“

erzeugt einen Schlüssel für das Netzwerk, der in den noch leeren Teil von „Network“

geschrieben werden muss.

Quellcode 11: Inhalt von /etc/wpa_supplicant.conf [9]c t r l \ _ i n t e r f a c e = / v a r / run / w p a _ s u p p l i c a n tap \ _scan =1

ne twork =s s i d =" YourSSID "psk=YourPSK

Neben der „wpa_supplicant“ Konfiguration wird die Datei „network/interfaces“ verän-

dert, indem der WLAN-Adapter als Interface hinzugefügt und ihm eine feste IP gegeben

wird. Diese muss auch in dem zu verbindenden Router eingestellt werden.

Quellcode 12: Inhalt von /etc/network/interfaces [9]

Entwicklung eines Türüberwachungsprototyps 19

# i n t e r f a c e f i l e au to−g e n e r a t e d by b u i l d r o o t

a u t o l oi f a c e l o i n e t l o o p b a c k

a u t o wlan0i f a c e wlan0 i n e t s t a t i c

a d d r e s s 1 9 2 . 1 6 8 . 0 . 1 1 0netmask 2 5 5 . 2 5 5 . 2 5 5 . 0gateway 1 9 2 . 1 6 8 . 0 . 1

Ebenfalls sollte die Datei „/etc/init.d/S40Network“ geändert werden. Dort wird unter

anderem, wie zuvor erwähnt, ein Modprobe-Befehl ergänzt, um den Treiber für den

WLAN-Adapter in den Kernel zu laden. Dies ist notwendig, da es in RPi-Buildroot

keine „/etc/modules“ Konfiguration gibt, wie bei normalen Linux Distributionen, die in

einer Datei alle beim Booten zu ladenden Treiber auflistet. Außerdem wird eine Verbin-

dung via „wpa_supplicant“ zum WLAN aufgebaut und die IP-Adresse durch „dhcpcd“

gesetzt.

Quellcode 13: Ergänzungen zu /etc/init.d/S40Networking# ! / b i n / sh## S t a r t t h e ne twork . . . .#

# Debian i fupdown needs t h e / run / ne twork l o c k d i r e c t o r ymkdir −p / run / ne twork

c a s e ’ \ $1 ’ i ns t a r t )

echo ’ S t a r t i n g ne twork . . . ’modprobe 8192 cu/ s b i n / i f u p −aw p a _ s u p p l i c a n t − i wlan0 −D wext −c / e t c / w p a _ s u p p l i c a n t . con f −Bdhcpcd wlan0; ;

s t o p )echo −n ’ S t o p p i n g ne twork . . . ’/ s b i n / i fdown −a; ;

r e s t a r t | r e l o a d )’ \ $0 ’ s t o p’ \ $0 ’ s t a r t; ;

* )echo ’ Usage : \ $0 s t a r t | s t o p | r e s t a r t ’e x i t 1

e s a c

e x i t \ $ ?

6.1.4.3. Test des Systems Ein erster Test zeigte, dass das WLAN ohne Proble-

me arbeitet. Beim Starten der Kamerasteuerungsprogramme gab es jedoch eine Fehler-

meldung, die Folgendes anzeigte: „Failed to open vchiq instance“. Der Fehler konnte

schnell behoben werden, indem auf die letzte vorhandene Version von rpi-userland und

rpi-firmware manuell geupdatet wurde. Dazu wurden die Versionsnummer und Prüfsum-

men der beiden Pakete in RPi-Buildroot verändert. Nach der Fehlerbehebung erfolgte ei-

ne Kontaktaufnahme zum Entwickler, um ihm das aufgetretene Problem und die Lösung

Entwicklung eines Türüberwachungsprototyps 20

zuzuschicken. Der Fehler wurde daraufhin behoben. Ein anschließender Test zeigte, dass

nun auch die Kamerasteuerungsprogramme reibungslos funktionierten.

6.1.4.4. Vergleich verschiedener Bildübertragungstechnologien Nachdem die

Pakete für den WLAN-Betrieb und die allgemeine Firmware für den Raspberry Pi 2

ausgewählt und die Konfiguration des WLAN durchgeführt wurde, fehlten nur noch die

Pakete, die die Bildübertragung zum Server übernahmen. Es gibt verschiedene Möglich-

keiten, Bilder vom Raspberry Pi 2 zum Server zu schicken. Zum einen können einzelne

Bilderserien gesendet werden, zum anderen kann man ein Video streamen.

Der erste Test bezog sich auf die Versendung von einzelnen Bildern. Das Programm

Raspistill, das speziell für die Kamera entwickelt wurde, hat hierzu kontinuierlich Bil-

der gemacht und diese in einen „tmp“ Ordner abgelegt.

Quellcode 14: Kameraskript für einzelne Bilder [42]# ! / b i n / sh

w h i l e :do

r a s p i s t i l l −o / f t p / tmp . j p g −−t i m e o u t 1 − t l 800 − t 100000 −op 50 −w 1920 −h 1080done

Diese Bilder konnten dann von einem Programm weiterverarbeitet werden.

Der erste Übertragungsversuch wurde mithilfe eines File Transfer Protocol (FTP) Ser-

vers durchgeführt. Dazu benutzte man als Clientsoftware ncftp, denn sie bietet ein leicht

zu bedienendes Command Line Tool namens ncftpput an. Parameter wie Username,

Passwort und die zu übertragende Datei werden direkt an das Terminal übergeben. [8]

Das ist zum einen praktisch, da nicht viel konfiguriert werden muss, zum anderen aber

auch durch die direkte Eingabe der unverschlüsselten Login-Daten sehr unsicher. Soll-

ten diese Daten in die falschen Hände gelangen, kann ein Dritter unbemerkt auf den

Server zugreifen. Die Übertragungsrate war zudem sehr langsam, da für jede Datei eine

neue Session geöffnet wurde. Somit konnte maximal ein Bild pro Sekunde übertragen

werden.

Quellcode 15: FTP-Skript für einzelne Bilder# ! / b i n / sh

w h i l e :do

n c f t p p u t −u username −p p a s s w o r t i p / home / username / f t p / / f t p / tmp . j p gs l e e p 1

done

Der nächste Versuch wurde mit einem Tool durchgeführt, das Secure Copy Protocol

(SCP) heißt und einen verschlüsselten Transfer von Daten anbietet. Dazu kann ein pri-

Entwicklung eines Türüberwachungsprototyps 21

vater und öffentlicher Schlüssel vom Client erstellt werden, der eine Passworteingabe

überflüssig macht. Der private Schlüssel wird behalten, der öffentliche Schlüssel muss

hingegen zum Server geschickt und in eine Liste mit autorisierten Schlüsseln eingetra-

gen werden. [11] Um dieses Tool zu aktivieren, ist es notwendig, zuvor OpenSSH im

Konfigurationsmenü von Buildroot auszuwählen und das System neu zu kompilieren.

Danach können Daten verschlüsselt vom Client zum Server geschickt werden. Das Pro-

blem war hier ebenfalls die sehr langsame Übertragungsrate. Hoch auflösende Bilder

benötigten bis zu einer Sekunde, bis sie auf dem Server dargestellt wurden.

Quellcode 16: SCP-Skript für einzelne Bilder# ! / b i n / sh

w h i l e :do

scp / f t p / tmp . j p g hl inka@192 . 1 6 8 . 0 . 1 0 3 : f t ps l e e p 1

done

Der Versuch mit einzelnen Bildern scheiterte somit an der Übertragungsrate der einge-

setzten Programme. Ein Video zu streamen, schien deshalb im ersten Moment unmög-

lich.

Der Raspberry Pi 2 kann durch das Programm Raspivid komprimierte Videos aufzeich-

nen, die entweder gespeichert oder weitergeleitet werden können. Für dieses Projekt ist

eine Weiterleitung vorgesehen. Dennoch könnten später noch Aufnahmen auf ein exter-

nes Speichermedium abgelegt werden, falls dies gewünscht wird.

Um das Video zu übertragen, wurden zwei Programme getestet. Das erste Programm

heißt GStreamer und bezeichnet sich selbst als „cross-platform multimedia framework“.

[39] Das Framework besteht aus zahlreichen Komponenten und kann sowohl simple als

auch komplexe Multimediadateien verarbeiten. Zur Installation via Buildroot benötigt es

jedoch etwas Zeit, da es durch die unzähligen Komponenten kaum eine Dokumentation

gibt, die alles erklärt. Aus diesem Grund wurde eine Anleitung für den Raspberry Pi 2

genutzt, die eigentlich für Raspian vorgesehen war. Dabei wird das Video von Raspivid

an GStreamer übergeben. Dieser bietet den Stream auf Port 5000 an.

Quellcode 17: GStreamer Befehl zum Starten eines Streams [1]r a s p i v i d − t 0 −h 1080 −w 1920 −f p s 15 −o − | g s t−l aunch −1.0 −v f d s r c ! h 2 6 4 p a r s e !r t p h 2 6 4 p a y c o n f i g− i n t e r v a l =1 p t =96 ! gdppay ! t c p s e r v e r s i n k h o s t =YOUR_RPI_IP_ADDRESS p o r t =5000

Quellcode 18: GStreamer Befehl zum Empfangen eines Streams [1]g s t−l aunch −1.0 −v t c p c l i e n t s r c h o s t =<IP−OF−THE−RPI> p o r t =5000 ! gdpdepay ! r t p h 2 6 4 d e p a y ! avdec_h264 !v i d e o c o n v e r t ! a u t o v i d e o s i n k sync = f a l s e

GStreamer muss dafür zunächst in Buildroot aktiviert werden. Dessen Eintrag ist je-

doch nur über die Suchfunktion auffindbar, da es von einer anderen Option abhängig

Entwicklung eines Türüberwachungsprototyps 22

ist. Leider zeigt Buildroot keine Pakete an, die durch Aktivierung von Abhängigkeiten

ausgewählt werden können. Die auszuwählenden Abhängigkeiten von Paketen können

leider nur in der Suchfunktion gefunden werden. Deshalb musste nach der Suche zuerst

die Option „Toolchain > Enable WHCHAR support“ ausgewählt werden, bevor GStre-

amer unter „Target Packages > Audio and video applications“ angezeigt wird. Nach der

Auswahl von GStreamer erscheinen weiterhin unter „Target Packages > Audio and video

applications“ weitere Pakete, die zuvor nicht sichtbar waren. Eine Liste aller auszuwäh-

lenden Pakete wird nachfolgend dargestellt.

Quellcode 19: Auszuwählende Raspberry Pi 2 PaketeT o o l c h a i n / Enab le WCHAR s u p p o r tT a r g e t Packages / Audio and v i d e o a p p l i c a t i o n s / g s t r e a m e r 1 . x / e n a b l e command−l i n e −p a r s e rT a r g e t Packages / Audio and v i d e o a p p l i c a t i o n s / g s t r e a m e r 1 . x / e n a b l e t r a c i n g subsys t emT a r g e t Packages / Audio and v i d e o a p p l i c a t i o n s / g s t r e a m e r 1 . x / e n a b l e g s t−debug t r a c e s u p p o r tT a r g e t Packages / Audio and v i d e o a p p l i c a t i o n s / g s t r e a m e r 1 . x / p l u g i n r e g i s t r yT a r g e t Packages / Audio and v i d e o a p p l i c a t i o n s / g s t r e a m e r 1 . x / i n s t a l l g s t−l a u n c h & g s t−i n s p e c tT a r g e t Packages / Audio and v i d e o a p p l i c a t i o n s / g s t−p l u g i n s −base / t c pT a r g e t Packages / Audio and v i d e o a p p l i c a t i o n s / g s t−p l u g i n s −good / r t pT a r g e t Packages / Audio and v i d e o a p p l i c a t i o n s / g s t−p l u g i n s −bad / gdpT a r g e t Packages / Audio and v i d e o a p p l i c a t i o n s / g s t−p l u g i n s −bad / v i d e o p a r s e r s

Nachdem alle Pakete ausgewählt wurden, konnte endlich die Kompilierung gestartet

und auf dem System getestet werden. Die Kompilierung verlief einwandfrei. Der Test

auf dem Raspberry Pi 2 hingegen meldete den Fehler, dass Gdppay nicht gefunden wur-

de. Normalerweise ist Gdppay im Paket GDP enthalten. Scheinbar besteht ein Fehler

in der installierten Version von GStreamer. Diese wies die Version 1.4.5 auf, aktuell ist

aber die Version 1.6 von GStreamer. Nachdem alle Makefiles und Prüfsummen manuell

von 1.4.5 auf 1.6 geupdatet wurden, funktionierte der Stream einwandfrei. Zur Überra-

schung wurde ein Full-HD-Bild mit 15 Frames pro Sekunde und einer geringen Latenz

angezeigt. Ein Kritikpunkt ist jedoch der Einbruch der Bilder pro Sekunde nach etwa 15

Minuten, der wahrscheinlich durch den hohen Speicherbedarf des Programmes hervor-

gerufen wurde.

GStreamer ist ein gutes Tool zum Streamen von Multimediadateien. Es bietet unzählige

Plug-ins an und kann Videos noch nach dem Stream nachbearbeiten. Die Dokumenta-

tion des Programmes und der Plug-ins ist leider, wie bei vielen anderen Open-Source-

Projekten, noch nicht sehr ausgereift. Ohne intensive Recherche hätte der Stream nicht

funktionieren können. Als Beispiel wäre hier der Codec H264 zu nennen. In einer älte-

ren Version wurde dieser separat in einem Plug-in mitgeliefert. Jetzt befindet er sich in

einem Plug-in namens Videoparser. Erst nach Recherche in zahlreichen Foren wurde ein

Hinweis dazu gefunden, dass sich der Codec jetzt in diesem Plug-in befindet.

Ein weiterer Kritikpunkt ist die nicht vorhandene Timeout-Funktion. Diese steuert, ab

wann der Empfänger den Stream abbricht und wieder auf den Sender wartet. Momentan

Entwicklung eines Türüberwachungsprototyps 23

friert das Video ein, sobald der Raspberry Pi 2 neu startet. Ein Ticket wurde diesbezüg-

lich schon erstellt. Es wurde auch schon bekannt gegeben, dass man sich um das Problem

in der Zukunft kümmern wird.

Nach den vielen Problemen mit GStreamer rückte nach Recherche ein anderes Pro-

gramm näher in den Fokus. Es heißt Netcat und übernimmt die Kommunikation über

Netzwerkverbindungen. [38] Dabei handelt es sich nicht nur um die Übertragung von

Multimediadateien, sondern es können auch normale Dateien problemlos von einem

Sender zum Empfänger geschickt werden. Dafür muss jedoch der Empfänger ständig

bereit sein, die Datei zu empfangen.

Dieses Szenario ist optimal, da der Sender, hier der Raspbery Pi 2, direkt eine Datei

an den Server schicken soll. Der Empfänger stellt somit die Basisstation dar und soll

ständig überprüfen, ob der Raspberry Pi 2 eine Datei schicken möchte.

Die Einrichtung von Netcat ist denkbar einfach, da nur zwei Optionen in Buildroot aus-

zuwählen sind.

Quellcode 20: Auszuwählende Pakete für NetcatT a r g e t Packages / Show p a c k a g e s t h a t a r e a l s o p r o v i d e d by busyboxNetworking a p p l i c a t i o n s / n e t c a t

Der anschließende Test gelang ohne weitere Probleme. Der Stream wurde vom Raspber-

ry Pi 2 zum Server geschickt und mit einem Programm namens MPlayer dargestellt.

Es besteht sogar die Möglichkeit der Basisstation, einen Timeout-Wert zu übergeben.

Nach Ablauf dieses Timeout wird der Stream abgebrochen. Sobald der Raspberry Pi 2

nun herunterfährt, unterbricht die Basisstation den Stream und wartet darauf, dass dieser

wieder startet.

Quellcode 21: Sendebefehl Netcat [42]r a s p i v i d − t 0 −w 300 −h 300 −hf −f p s 20 −o − | nc <IP−OF−THE−CLIENT> 2222

Quellcode 22: Empfängerbefehl Netcat [42]nc −w 1 − l −p 2222 | mplayer −f p s 200 −demuxer h264es −

Ein schneller Vergleichstest zeigte zudem, dass Netcat eine geringere Latenz beim Stre-

amen hat als GStreamer. Um dies zu verdeutlichen, wurde eine einfache digitale Stopp-

uhr genutzt, die von der Kamera aufgezeichnet wurde. Der Raspberry Pi 2 stellte die

Originalaufnahme links dar. Ein anderer PC empfing den Stream auf einem zweiten

Bildschirm, der rechts zu sehen ist. Durch die Aufnahme beider Bildschirme kann eine

ungefähre Aussage zur Latenz gegeben werden. Zu beachten ist, dass die Reaktionszeit

der Kamera und des Bildschirms noch hinzugerechnet werden müssen und sich je nach

Entwicklung eines Türüberwachungsprototyps 24

Konfiguration des Testaufbaus verändern können. Diesen Nachteil hatte sowohl GStrea-

mer als auch Netcat. Somit sollte bei beiden dieselbe Abweichung vorliegen.

Abbildung 6: Latenztest von GStreamer

Die Latenz von GStreamer betrug 439 ms bei einer Auflösung von 1920 x 1080 und 15

Bildern pro Sekunde. Es handelt sich hier an sich schon um einen sehr guten Wert.

Abbildung 7: Latenztest von Netcat

Entwicklung eines Türüberwachungsprototyps 25

Netcat schaffte sogar eine Latenz von nur 100 ms bei einer Auflösung von 1920 x 1080

und 15 Bildern pro Sekunde. Das ist deutlich schneller als GStreamer. Ein Qualitätsun-

terschied, wie verstärkte Bildfragmente bei einem der getesteten Programme, war zwi-

schen den beiden Streams nicht zu erkennen.

Letztendlich wurde Netcat ausgewählt, die Übertragung von Bildern zu übernehmen.

Die Gründe hierzu waren die reibungslose Konfiguration, die sehr gute Latenz, die gute

Bildqualität und die Möglichkeit, den Stream nach einem Timeout neu zu starten, ohne

dass er einfriert.

Um Netcat beim Booten mit Raspivid zu starten, wurde es noch mit in „/etc/init.d/S40Network“

geschrieben. Damit wird der Befehl direkt nach dem Netzwerkstart ausgeführt.

Quellcode 23: Ergänzungen zu /etc/init.d/S40Networking# ! / b i n / sh## S t a r t t h e ne twork . . . .#

# Debian i fupdown needs t h e / run / ne twork l o c k d i r e c t o r ymkdir −p / run / ne twork

c a s e ’ \ $1 ’ i ns t a r t )

echo ’ S t a r t i n g ne twork . . . ’modprobe 8192 cu/ s b i n / i f u p −aw p a _ s u p p l i c a n t − i wlan0 −D wext −c / e t c / w p a _ s u p p l i c a n t . con f −Bdhcpcd wlan0

r a s p i v i d − t 0 −w 1920 −h 1080 −f p s 15 −o − | nc <IP−OF−THE−CLIENT> 2222; ;

s t o p )echo −n ’ S t o p p i n g ne twork . . . ’/ s b i n / i fdown −a; ;

r e s t a r t | r e l o a d )’ \ $0 ’ s t o p’ \ $0 ’ s t a r t; ;

* )echo ’ Usage : \ $0 s t a r t | s t o p | r e s t a r t ’e x i t 1

e s a c

e x i t \ $ ?

Der Empfänger des Streams lässt ein Skript im Hintergrund laufen, das eine Dauer-

schleife erzeugt und den Stream nach jedem Abbruch erneut startet. Im Moment wird die

Übertragung an den MPlayer, ein Programm zum Darstellen von Videos, weitergeleitet.

Später kann dieser Stream direkt zu OpenCV geleitet werden, um eine Personenerken-

nung durchzuführen.

Quellcode 24: Netcat Serverskript# ! / b i n / sh

w h i l e :do

Entwicklung eines Türüberwachungsprototyps 26

nc −w 1 − l −p 2222 | mplayer −f p s 200 −demuxer h264es −done

Die Entwicklung der Raspberry Pi 2 Firmware war damit abgeschlossen.

6.2. Bewegungssensoren

Einer der wichtigsten Komponenten des Systems ist der Bewegungssensor, denn er mel-

det Objekte, die sich in seinem Sichtradius bewegen. Damit entscheidet er darüber, ob

das Kamerasystem früh genug gestartet wird. Um den perfekten Sensor zu finden, wur-

den drei verschiedene Technologien sowohl theoretisch als auch praktisch betrachtet und

deren Stärken und Schwächen ermittelt.

Die getesteten Bewegungssensoren sind für unterschiedliche Einsatzzwecke gedacht, er-

füllen aber alle notwendigen Eigenschaften der Bewegungserkennung. Dazu gehört die

schnelle Abfrage von Messwerten ebenso wie die Einsatzbereitschaft in unterschiedli-

cher Lichtumgebung. Besonders nachts erkennen die Sensoren Bewegungen genauso gut

wie tagsüber. Normale Kameras mit Bilderkennungssoftware müssen meist zusätzliche

Infrarotleuchtdioden einsetzen, um überhaupt etwas zu erkennen.

6.2.1. Pyroelektrischer Sensor

Zu Beginn wird eine Technologie vorgestellt, die fast jeder bei sich zu Hause im Ein-

satz hat. Standardmäßig werden in vielen Produkten pyroelektrische Sensoren, auch In-

frarotsensoren genannt, verbaut. Sie nutzen zur Erkennung abgestrahlte Wärmeenergie

von sich bewegenden Objekten und können so zwischen lebendigen und nicht leben-

digen Objekten differenzieren. Um einen Unterschied zu erkennen, besitzt der Sensor

zwei nebeneinander liegende Kristalle. Trifft nun Infrarotstrahlung in einer bestimmten

Frequenz auf einen der Kristalle, erzeugt diese eine andere Spannung als der daneben

liegende. Kurz darauf trifft die Infrarotstrahlung dann auch auf den zweiten Kristall. Es

entsteht durch den Spannungsunterschied ein Signal, das durch einen regelbaren Verstär-

ker in ein digitales Signal umgewandelt werden kann. [54]

Wenn der Sensor nur Strahlung empfängt, aber nicht aktiv sendet, spricht man auch von

einem passiven Sensor. [54] Passive Sensoren haben den Vorteil, dass sie viel weniger

Energie verbrauchen als ihre aktiven Gegenparts. Das ist auch bei dem in diesem Projekt

genutzten HC-SR501 der Fall. Er verbraucht weniger als 1 mA und kann wahlweise mit

5,0 V oder, nach leichter Modifizierung durch Anlöten eines weiteren Stiftes [55], mit

3,3 V betrieben werden. Auf der Rückseite des Sensors sind weitere Stifte angebracht.

Entwicklung eines Türüberwachungsprototyps 27

Darunter befindet sich „OUT“ der mit dem einem digitalen GPIO des Mikrocontrollers

verbunden wird. Zudem sind zwei Regler mit auf dem Board verbaut, die die Sensibilität

und Wartezeit zwischen zwei erkannten Objekten regeln. Der Sensor hat keine automa-

tische Regelung und muss deshalb manuell auf die Gegebenheiten vor Ort eingestellt

werden. Das kann je nach Einsatzgebiet schwierig werden, wenn sich z. B. draußen die

Wetterbedingungen ändern. Eine ständige Neujustierung wäre für den Anwender ärger-

lich, denn wird der Sensor falsch konfiguriert, kann dies zu häufig auftretenden Fehlalar-

men führen.

Der HC-SR501 besitzt eine Fresnel Linse aus High-Density-Polyethyle. Dieses Mate-

rial senkt die Kosten gegenüber Silizium basierten Linsen, hat aber den Nachteil, dass es

eine sehr hohe Dämpfung für Wärmestrahlung aufweist. 0,1 mm absorbieren bereits 15

Prozent der Strahlung und eignen sich deshalb weniger für die Herstellung herkömmli-

cher Linsen. Durch den Einsatz von Fresnel Linsen kann der Dämpfungseffekt soweit

verringert werden, dass sich ein Einsatz wieder lohnt. Die Linse weist dafür dünne, ver-

schieden angewinkelte Segmente auf, um das Erfassungsfeld des Sensors zu vergrößern,

ohne die zur Bewegungserkennung erforderliche Wärmestrahlung zu stark zu absorbie-

ren. [58]

Abbildung 8: Beide Seiten des pyroelektrischen Sensors mit abgebauter Fresnel Linse

6.2.2. Ultraschallsensor

Der zweite getestete Sensor nutzt Ultraschall zur Bewegungserkennung. Er sendet und

empfängt immer im Wechsel Ultraschallwellen. Die ausgesendeten Schallwellen wer-

den von Objekten reflektiert und vom Empfänger ausgewertet. Zwischen dem Senden

und Empfangen jeder Schallwelle wird die Zeit gemessen, die sich proportional zum

Abstand verhält. Aus diesem Verhältnis kann der genaue Abstand errechnet werden. [29]

Die Firma Maxbotix stellt sehr kleine Ultraschallsensoren her, die sich auch für die Per-

sonenerkennung eignen. In diesem Test wird der Maxbotix MB1210 XL-MaxSonar®-

Entwicklung eines Türüberwachungsprototyps 28

EZ1™ genutzt. Er bietet eine Auflösung von 1 cm bei einem Abstand von maximal 765

cm. Zudem besitzt er eine automatische Kalibrierung, die sich je nach Spannung, Luft-

feuchtigkeit und Umgebungslautstärke anpasst. Sein Stromverbrauch wird im Mittel mit

3.4 mA angegeben, was aufgrund seiner aktiven Eigenschaft als bemerkenswert zu er-

achten ist. Es können aber auch Spitzen von 50 mA erreicht werden. Leider beschränkt

sich sein Einsatzgebiet auf beheizte Räume. Empfohlen wird der Betrieb zwischen 0 bis

65 Grad Celsius, obwohl er mit bis zu - 40 Grad Celsius funktionieren soll. [29] Speziell

für den Außenbetrieb bietet Maxbotix IP67 zertifizierte Ultraschallsensoren an. Diese

Zertifizierung spiegelt sich aber deutlich im Preis wider und würde den Rahmen dieser

Arbeit sprengen.

Der Sensor hat fünf Lötaugen, wobei zwei von „VCC“ und „GND“ belegt werden. Die

Eingangsspannung von „VCC“ kann zwischen 3,3 V und 5,5 V betragen. Sie werden

deshalb mit denselben 3,3 V verbunden, die der im nächsten Kapitel beschriebene Mi-

krocontroller zur Stromversorgung nutzt. Zum Schluss muss noch Pin 3 mit einem ana-

logen Eingang des Mikorcontrollers verbunden werden.

Abbildung 9: Ultraschallsensor

6.2.3. Radarsensor

Der letzte Sensor im Test verwendet Radartechnologie. Es ist in Deutschland nicht

ganz leicht, erlaubte Radarsensoren für private Prototypen zu beziehen. Die meisten

Projekte, die im Vorfeld angesehen wurden, nutzen einen Radarsensor in den 10,525

GHz-Bereichen. In manchen Ländern ist dies kein Problem, in Deutschland hingegen

ist der Bereich nach der Bundesnetzagentur dem Reportagefunk zugewiesen und er-

möglicht die Übertragung von Bild- und Tonsignalen. Erlaubt ist Radar in Deutschland

z.B. unter anderem im 24 GHz-Band. [52] Durch diese spezielle gesetzliche Situati-

on war es nicht ganz einfach, einen geeigneten Sensor zu finden. Es gibt trotz allem

Entwicklung eines Türüberwachungsprototyps 29

Händler, die einen geeigneten Sensor vertreiben, jedoch nur wenige, die den passenden

Niederfrequenz (NF)-Vorverstärker gleich mitliefern. Der Verstärker ist wichtig, da das

Ausgangssignal des Sensors sehr schwach ist. Um es für den Mikrocontroller nutzbar zu

machen, wird es deshalb durch einen NF-Vorverstärker verstärkt.

Ein Radarsensor funktioniert, ähnlich wie der Ultraschallsensor, nach dem Doppler-

Prinzip. Er sendet im 24 GHz-Band ein Signal aus und wartet darauf, dass das Signal

von einem Objekt reflektiert wird. Die Reflexion wird wieder empfangen und als eine

Spannungsspitze in einem analogen Signal ausgegeben. [4] Vorteil eines Radarsensors

ist es, dass er nicht von Umwelteinflüssen beeinflusst wird. [60] Das qualifiziert ihn be-

sonders für Außeneinsätze. Zudem kann er Objekte durch Plastik erkennen und damit

nicht sichtbar hinter einer Abdeckung stecken. Diese Abdeckung schützt ihn zusätzlich

vor Umwelteinflüssen.

Für dieses Projekt wird ein 24 GHz Continuous Wave (CW)-Radarsensor mit einem

40 bis 73 dB einstellbaren NF-Vorverstärker getestet. Der Radarsensor wird von der Fir-

ma InnoSent hergestellt und heißt IPM-165. Der Vorverstärker kommt von der Firma

Weidmann-Elektronik.

Das Board besitzt sechs Stifte, zum Einsatz kommen jedoch nur die schwarzen, da es

sich bei den anderen um die Kontakte für den NF-Vorverstärker handelt. Diese Kontakte

sind extrem empfindlich gegenüber statischer Aufladung und sollten, wenn überhaupt,

nur nach eigener Erdung berührt werden. Der Hersteller empfiehlt, den Sensor nur an

der Seite anzupacken. [35]

Die drei schwarzen Stifte sind mit „VCC“, „GND“ und „SOUT“ belegt. Die Versor-

gungsspannung liegt zwischen 4,75 und 5,00 V. Um von den 3,3 V auf die benötigte

Spannung von 4,75 V zu kommen, wird ein Spannungswandler mit relativ schwacher

Brummspannung genutzt, um Messfehler zu vermeiden. Diese treten schon bei einer

Stromversorgung durch USB auf. [61]

„VCC“ und „GND“ werden mit dem Spannungswandler verbunden. Der Spannungs-

wandler nutzt die Stromversorgung des Mikrocontrollers. Dennoch muss vom Radar-

sensor ein zweites „GND“ zum Mikrocontroller führen, da es ansonsten zu keinem Po-

tentialausgleich kommt und die Messwerte verfälscht werden.

Entwicklung eines Türüberwachungsprototyps 30

Abbildung 10: Beide Seiten des Radarsensors IPM-165 mit Vorverstärker

Nachdem die Sensoren vorgestellt wurden, werden diese nun miteinander verglichen.

Dieser Vergleich soll vor allem die Reichweite bis zur Objekterkennung und den Strom-

verbrauch thematisieren.

6.2.4. Reichweite der Sensoren

Die Reichweite entscheidet, ob eine Person rechtzeitig erkannt wird und damit auch, ob

der Raspberry Pi 2 genügend Zeit hat, um zu starten. Geht man von einer durchschnitt-

lichen Gehgeschwindigkeit von 2,9 km/h aus [16], also 0,8 m/s, braucht man für eine

Bootzeit von zehn Sekunden mindestens acht Meter. Hinzu kommt natürlich noch die

Reaktionszeit des Bewohners, womit die minimale Reichweite auf sechs bis sieben Me-

ter sinkt.

Abbildung 11: Test der Sensorreichweite

Der Test wurde bei einer Außentemperatur von 14 Grad Celsius im Freien durchge-

führt. Vor den Sensoren lag ein Maßband mit einer Gesamtlänge von elf Metern. Bei der

Durchführung näherte sich eine Person in Gehgeschwindigkeit dem Sensor. Sobald der

Entwicklung eines Türüberwachungsprototyps 31

Sensor die Person erkannt hatte, wurde der Abstand notiert. Pro Sensor wurde der Test

zehnmal wiederholt.

Die Durchführung des ersten Tests erfolgte mit dem Radarsensor IPM-165. Der Vor-

verstärker wurde dazu auf die maximale Einstellung gestellt.

Tabelle 2: Testreichweite des RadarsensorsTest Abstand1 6,70 Meter2 7,20 Meter3 6,80 Meter4 6,10 Meter5 7,50 Meter6 7,00 Meter7 6,20 Meter8 6,30 Meter9 5,50 Meter10 5,80 Meter

Das arithmetische Mittel beträgt 6,51 Meter. Damit liegt der Sensor knapp über der mi-

nimalen Reichweite.

Als zweiter Sensor wurde der Ultraschallsensor Maxbotix MB1210 XL-MaxSonar®-

EZ1™ getestet. Der Sensor ist so konfiguriert, dass er Unterschiede zentimetergenau

erkennt und laut Hersteller eine Reichweite von 765 cm hat. Deshalb wurde getestet,

ob eine Person in diesem Abstand erkannt wird. Anders als bei den anderen Sensoren,

musste sich die Person dazu nicht auf den Sensor hinzubewegen.

Der Sensor zeigte eine maximale Reichweite von 6,18 Metern an. Auch nach Anpassun-

gen des Winkels wurden die 7,65 Meter nicht erreicht. Dafür erkennt der Sensor flache

Objekte, wie eine Europalette mit den Maßen 1200 x 800 cm, in der Entfernung von 618

cm genau. Bei Menschen schwankt die Erkennung teils zwischen dem realen und dem

maximalen Wert. Anscheinend bietet ein Mensch nicht genug Fläche zur Reflexion der

Ultraschallwellen. Sobald sich die Person dem Sensor nähert, nimmt der Störeffekt ab.

Der letzte Sensor HC-SR501 ist der einzige passive Sensor unter den getesteten. Er soll

auf bis zu sieben Meter Entfernung, mithilfe des pyroelektrischen Effekts, Personen er-

kennen.

Entwicklung eines Türüberwachungsprototyps 32

Tabelle 3: Testreichweite des pyroelektrischen SensorsTest Abstand1 9,20 Meter2 8,50 Meter3 7,70 Meter4 8,70 Meter5 8,10 Meter6 8,30 Meter7 8,10 Meter8 7,90 Meter9 7,70 Meter10 7,50 Meter

Das arithmetische Mittel beträgt hier 8,17 Meter. Das liegt über den versprochenen 7

Metern und erfüllt sogar die Anforderung ohne die Reaktionszeit des Bewohners.

In der Kategorie Reichweite gewinnt somit der HC-SR501 mit 8,17 Metern vor dem

Radarsensor IPM-165 mit 6,51 Metern. Der Ultraschallsensor Maxbotix MB1210 XL-

MaxSonar®EZ1™ scheitert hingegen an der Personenerkennung im Freien.

6.2.5. Stromverbrauch der Sensoren

Nach der Reichweite wird der Stromverbrauch jedes Sensors überprüft. Der Unterschied

zwischen aktiven und passiven Sensoren ist dabei deutlich erkennbar. Der pyroelektri-

sche Sensor verbraucht im Stand-by nur einen Bruchteil seiner aktiven Konkurrenten.

Dabei ist der reale Verbrauch noch einmal kleiner, wenn kein Objekt erkannt wird. In

diesem Fall muss der Sensor kein analoges Signal in ein digitales Signal umwandeln

und braucht damit keine zusätzliche Energie.

Tabelle 4: Stromverbrauchsmesswerte der SensorenStatus StromverbrauchPyroelektrischer Sensorohne Signal

0,04 mA

Pyroelektrischer Sensormit Signal

0,85 mA

Ultraschallsensor 2,17 mARadarsensor 64,47 mA

Betrachtet man diese Werte in Bezug darauf, dass das System möglichst lange laufen

soll, kann in diesem Fall nur der passive Sensor empfohlen werden. Sein Stromverbrauch

Entwicklung eines Türüberwachungsprototyps 33

ist so niedrig, dass er auf die Laufzeit fast keine Auswirkungen hat. Im Gegensatz dazu

verbrauchen die aktiven Sensoren um das Vielfache mehr Strom. Dabei ist der Ultra-

schallsensor noch ziemlich sparsam, der Radarsensor sollte hingegen nur bei nicht Akku

betriebener Anwendung zum Einsatz kommen.

6.2.6. Ergebnis des Sensoren Vergleichs

Der pyroelektrische Sensor hat in beiden Kategorien überzeugt und wird damit fester

Bestandteil des Systems. Zwar muss dieser zunächst manuell konfiguriert werden und

besitzt keine eigene Anpassung an die Gegebenheiten der Umwelt, doch nachdem die

optimalen Einstellungen gefunden wurden, erkennt er die Objekte sehr zuverlässig und

stromsparend.

6.3. Arduino Mikrocontroller

Dieses Unterkapitel behandelt den Bau und die Programmierung des Arduino Mikrocon-

trollers mitsamt seinen Sensoren und dem Relais. Ziel ist es, dass der Mikrocontroller

mithilfe von Bewegungssensoren ein Relais steuert, das den Raspberry Pi 2 anschaltet,

sobald eine Kameraübertragung benötigt wird.

6.3.1. Das Board

Im Bereich der Arduino Mikrocontroller muss sich zuerst für zwei verschiedene Arten

von Boards entschieden werden. Es gibt Boards, die standardmäßig mit 5,0 V betrieben

werden. Sie lassen sich dadurch leicht durch einen USB-Netzteil versorgen. Boards mit

3,3 V Eingangsspannung sind jedoch auf dem Vormarsch. Das liegt vor allem daran,

dass diese leicht durch kleine Batterien und Akkus versorgt werden können. Außerdem

erlauben viele Arduino kompatible Sensoren, Displays und andere Zusatzboards nur ei-

ne niedrige Eingangsspannung. [5] Aus diesem Grund ist es sinnvoller, ein niedriger

versorgtes Board zu nutzen. Wenn z. B. Daten von einem 5,0 V Modul zu einem 3,3 V

Modul geschickt werden müssen, muss dieser Spannungsunterschied mit einem zusätz-

lichen Spannungswandler gelöst werden, um das 3,3 V Modul nicht zu beschädigen. Zur

Umgehung dieses Problems ist es ratsam, von vornherein einen 3,3 V Arduino Mikro-

controller zu nutzen.

Verwendet wird in diesem Projekt ein Arduino Pro Mini, der mit 8 MHz taktet und

einen ATmega328 Chipsatz besitzt. Das Board des Arduino ist so designt, dass die 14

Digitale, sechs davon mit Pulsweitenmodulation (PWM) Ausgang und acht analogen

Entwicklung eines Türüberwachungsprototyps 34

GPIOs horizontal ausgerichtete Kontakte leicht zugänglich sind. Zudem befinden sich

sechs Kontakte vertikal auf dem Board, die eine Stromversorgung und die Verbindung

zu einem Programmierer durch beispielsweise einem Universal Asynchronous Receiver

Transmitter (UART)-USB-Konverter ermöglichen. [22]

Der Mikrocontroller wird zunächst auf ein „Adafruit Perma-Proto Quarter-sized Bread-

board PCB“ gelötet. Diese Steckplatine besitzt mehrere durchkontaktierte Kontakte. An

den Seiten befinden sich zudem weitere Kontakte für die Stromversorgung. Die Platine

hilft dabei, weitere Komponenten auch noch in einer späteren Phase des Projektes nach-

zurüsten. Nachdem der Arduino auf die Steckplatine gelötet wurde, sollte unbedingt

geprüft werden, ob die Verbindungen fest sitzen und keine kalten Lötstellen entstan-

den sind. Bei kalten Lötstellen befindet sich keine richtig feste Verbindung zwischen

dem Lot und dem Lötauge. Somit leitet die Stelle schlecht und löst sich schon nach

leichten Erschütterungen. Wenn alle Lötstellen in Ordnung sind, muss noch eine Prü-

fung mit dem Multimeter stattfinden. Zwei nebeneinander liegende Lötstellen könnten

im schlimmsten Fall nicht sichtbare Verbindungen besitzen, die zu einem Kurzschluss

führen würden. [37]

Zusätzlich wurde direkt nach dem Löten mit einem Skalpell und einer Lupe eine Leiter-

bahn einer ständig angeschalteten Status-Leuchtdiode durchtrennt. Dies spart im Betrieb

bis zu 3 mA ein. Dies klingt zunächst nach nicht viel, wird sich aber am Ende auszah-

len. [17]

6.3.2. Raspberry Pi 2 Relais

Nicht alle Komponenten des Prototyps laufen mit derselben Versorgungsspannung. Aus

diesem Grund muss an bestimmten Stellen die Spannung angehoben werden, um z. B.

die benötigten 5,0 V des Raspberry Pi 2 bereitzustellen. Das Thema der Stromversor-

gung wird im nachfolgenden Kapitel ausführlicher behandelt werden. Dennoch erfolgt

an dieser Stelle schon ein kurzer Bezug darauf, da neben der Anhebung der Spannung

auch die Schaltung des Raspberry Pi 2 mit derselben Komponente realisiert wird.

Der vorgeschaltete Spannungswandler der Firma Adafruit hebt die Spannung des Lithium-

Polymer-Akku (LiPo) auf stabile 5,2 V und bietet zusätzlich die Möglichkeit, die Strom-

versorgung zu unterbrechen, indem man die Kontakte „En“ und „GND“ miteinander ver-

bindet. Diese Funktion wird genutzt, um mit dem Arduino Mikrocontroller den Raspber-

ry Pi 2 an- und auszuschalten. Zu diesem Zweck muss eine kleine Schaltung erstellt wer-

den, die über ein regelbares Relais den Kontakt zwischen „EN“ und „GND“ regelt. [41]

Entwicklung eines Türüberwachungsprototyps 35

Es gibt verschiedene Arten von Relais für unterschiedliche Einsatzmöglichkeiten. In die-

sem Fall fließt nur wenig Strom zwischen „EN“ und „GND“ und ermöglicht damit die

Nutzung eines kleinen Relais. Zuerst wurde aus diesem Grund ein Optokoppler mit gal-

vanischer Trennung genutzt. Bei einer galvanischen Trennung haben zwei Stromkreis-

läufe keinen direkten Kontakt miteinander. Sobald es in einen der beiden Kreisläufe

zu einer unerwarteten Spannungsspitze kommt, bleibt der andere Kreislauf davon ver-

schont. [40]

Der genutzte Optokoppler EL817 besitzt im Inneren einen Fototransistor und eine Infra-

rotleuchtdiode. Der Arduino steuert die Infrarotleuchtdiode und der Fototransistor des

Optokopplers regelt den Stromfluss durch einfallendes Licht. Sobald infrarotes Licht auf

den Transistor fällt, wird eine Basisspannung erzeugt, die den Halbleiter für Elektronen

durchlässig macht. [40] Genau dieser Effekt wird genutzt, um den Spannungswandler zu

schalten.

Der EL817 hat vier Anschlüsse, jeweils zwei für den Fototransistor und zwei für die

Leuchtdiode. Die Anode der Leuchtdiode ist durch einen kleinen Punkt gekennzeichnet.

Direkt unter der Anode liegt die dazugehörige Kathode. Die Versorgungsspannung des

Optokopplers darf maximal bei 1,4 V liegen, es werden jedoch 1,2 V empfohlen. [47]

Der Arduino Mikrocontroller liefert durch seine digitalen Ausgänge eine Spannung von

3,3 V. [22] Somit muss für den Betrieb des Optokopplers noch ein Spannungsabfall von

2,1 V erreicht werden. Zu diesem Zweck wird vor die Anode noch ein 56 Ohm Wider-

stand vorgesetzt, der den gewünschten Spannungsabfall bewirkt.

Die ersten Tests verliefen problemlos. Der Raspberry Pi 2 konnte sehr schnell ein- und

ausgeschaltet werden. Leider wurde erst später bemerkt, dass der Optokoppler perma-

nent im Stand-by einen vergleichsweise hohen Strom zieht und nur ausgeschaltet bleibt,

sobald der Raspberry Pi 2 betrieben wird. Dies ist aber nur in begrenzten Zeiträumen der

Fall, denn „EN“ und „GND“ müssen zur Abschaltung des Spannungswandlers Kontakt

haben. [41] Nach einer Messung stellte sich ein Stromverbrauch von 34 mA bei 3,3 V

heraus. Dies würde die Batterie im Stand-by zusätzlich belasten.

Entwicklung eines Türüberwachungsprototyps 36

Abbildung 12: Optokopplerschaltung

Nach dieser ernüchternden Erkenntnis wurde nach einem besseren Weg gesucht, den

Spannungswandler zu schalten. Perfekt wäre es, den Arduino direkt als Schalter zu nut-

zen, ohne dass er Schaden dabei nehmen würde. „EN“ hat jedoch eine Spannung von 3,7

V und liegt damit oberhalb der 3,3 V der digitalen GPIOs. In der sehr langen Dokumen-

tation des eingesetzten Chipsatzes ATMEGA328 des Arduino Pro Mini befinden sich auf

Seite 299 die absoluten Maximalwerte der GPIOs. Diese dürfen mit einer maximalen Be-

lastbarkeit von VCC ± 0,5 V betrieben werden. Damit kann jeder GPIO Pin, ausgehend

von einer 3,3 V Versorgungsspannung, maximal 3,8 V vertragen und liegt damit knapp

über den gemessenen 3,7 V. Das heißt, der Arduino kann direkt mit dem Spannungs-

wandler verbunden werden, ohne dass der Mikrocontroller Schaden nimmt. [23, S.299]

Der Arduino besitzt zum Schalten spezielle Pull-up-Widerstände im Bereich von 20k bis

50k Ohm, die durch die Firmware aktiviert werden können. Der Hersteller macht zu den

Widerständen leider nur eine Angabe, in welchem Bereich sich minimal und maximal

die Widerstände befinden können. Der Bereich hängt dabei von verschiedenen Werten,

wie z. B. der Versorgungsspannung und der Kapazität jedes einzelnen Pins, ab. [23] Dies

erschwert die Berechnung eines geeigneten Widerstands.

Zu diesem Zweck wurde mithilfe eines Messgeräts die Logik des Spannungswandlers

beobachtet. Diese besitzt, wie schon erwähnt, die Pins „EN“ und „GND“ und schaltet

je nach Zustand, den Wandler ein oder aus. Laut der Dokumentation von Texas Instru-

ment, die den genutzten Chipsatz TPS61090 herstellen, hat „EN“ dauerhaft den Zu-

stand „HIGH“. Sobald eine Verbindung zu „GND“ entsteht, bekommt er den Zustand

„LOW“. [48] Dabei verändern sich die Spannungswerte von 3,7 V auf 0,0 V. Die Logik

des Spannungswandlers benutzt so genannte Logikpegel, in der sie die jeweilige Span-

nung in „LOW“ oder „HIGH“ einteilt. Somit musste der richtige Widerstand gefunden

werden, um die Spannung an „EN“ in ausreichender Weise abfallen zu lassen, um ein

Entwicklung eines Türüberwachungsprototyps 37

„LOW“ zu erzeugen.

Zuerst wurde dafür nur der Arduino benutzt, der den Pin 10 als Eingang deklariert und

den Widerstand alle fünf Sekunden an- und ausschaltet.

Quellcode 25: Test des Relaisi n t r = 1 0 ;

vo id s e t u p ( ) pinMode ( r , INPUT ) ;d i g i t a l W r i t e ( r , HIGH ) ;

vo id loop ( ) d i g i t a l W r i t e ( r , HIGH ) ;d e l a y ( 5 0 0 0 ) ;d i g i t a l W r i t e ( r , LOW) ;d e l a y ( 5 0 0 0 ) ;

Diese fünf Sekunden reichten aus, damit sich die Spannung nach einem Schaltvorgang

wieder stabilisieren konnte. Sobald der Arduino bereit ist, verbindet man Pin 10 mit „En“

und „GND“ mit „GND“. Die gemessenen Werte zeigten eine verringerte Spannung von

3,6 V mit inaktiven Pull-up-Widerständen und 3,3 V mit aktiven Pull-up-Widerständen

an. Dies reichte nicht aus, um die Logik des Converters umzuschalten. Es musste des-

halb ein Weg gefunden werden, einen zusätzlichen Spannungsabfall herbeizuführen.

Parallel geschaltete Widerstände stellen eine Maßnahme dar, dies zu realisieren. Aus die-

sem Grund wurde parallel zum Arduino Widerstand ein weiterer an Pin 10 angebrachter

Widerstand mit Verbindung zu „GND“ eingebaut. Der Widerstand wurde zuerst von ei-

nem Potentiometer ersetzt, der es erlaubt, einen variablen Widerstand zu erzeugen. Die

genauen Ohm-Werte lassen sich dann durch ein Messgerät bestimmen.

Das genutzte Potentiometer erlaubte einen Widerstand bis zu 700k Ohm. Die Logik des

Spannungswandlers reagierte, sobald Werte von ungefähr 68k Ohm überschritten wur-

den. Maximal können Widerstände mit 150k Ohm eingesetzt werden. Darüber hinaus

reagiert die Logik nicht mehr.

Nachdem festgestellt wurde, dass ein paralleler Widerstand zwischen 68k Ohm und 150k

Ohm eingesetzt werden muss, wurde ein 100k Ohm zum Arduino Prototypboard hinzu-

gefügt. Die Schaltung funktionierte anschließend perfekt und verbrauchte im Gegenzug

zum Optokoppler keinen zusätzlichen Strom.

Entwicklung eines Türüberwachungsprototyps 38

6.3.3. Entwicklung der Firmware

Der Arduino hat eine eigene Entwicklungsumgebung namens Arduino IDE. Diese ist

komplett Open-Source und läuft auf allen wichtigen Plattformen wie Linux, Mac und

Windows. Sie kann von der Arduino Webseite kostenlos heruntergeladen werden und

besitzt schon die meisten Pakete, die man zur Entwicklung der Firmware eines Arduino

Mikrocontrollers braucht. [27]

Nachdem die Software heruntergeladen wurde, wird noch eine passende Verbindung

zum Mikrocontroller benötigt. Es gibt ein paar Modelle, die bereits über einen USB-

Anschluss verfügen und keinen separaten USB-Konverter brauchen. Die meisten Mi-

krocontroller besitzen jedoch eine spezielle Transistor-Transistor-Logik (TTL)-UART-

Schnittstelle, auch gerne serielle Schnittstelle genannt. Diese Schnittstelle ermöglicht

es, direkt mit dem Chipsatz zu sprechen und ihn zu programmieren. Hierfür wird ein

TTL-USB-Adapter benötigt. [22] Es kann ein Adapter mit z. B. CP2102 Chipsatz be-

nutzt werden. Dieser bietet die Möglichkeit, mit Arduinoboards mit 3,3 V und 5,0 V zu

sprechen. [51] Das ist wichtig, da 3,3 V Boards durch 5,0 V Adapter beschädigt werden

können, auch wenn diese nicht von dem Adapter mit Strom versorgt werden. Die TX-

Verbindung hat bei beiden Varianten unterschiedliche Spannungen und kann ein niedri-

ger ausgelegtes Board beschädigen. [5]

Die Installation des Adapters unter Linux ist sehr einfach, da der Chipsatz nicht ex-

tra installiert werden muss und sofort erkannt wird. Unter Windows müssen noch extra

Treiber von der Herstellerseite heruntergeladen werden. Problematisch ist, dass diese

Treiber über keine Windows-Verifizierung verfügen und sich nur über einen Trick in-

stallieren lassen. [50] Generell ist deshalb zu empfehlen, unter Linux zu arbeiten.

Um Kontakt zum Arduino mit dem Adapter aufzunehmen, müssen diese zunächst mit

drei Drähten verbunden werden. Zum einen gibt es eine RX-Verbindung, die Daten emp-

fängt und zum anderen eine TX-Verbindung, die Daten sendet. Die jeweiligen Kontakte

werden dazu in der folgenden Reihenfolge verbunden: „RX<->TX, TX<->RX“. Das

heißt, der TX-Kontakt auf dem Adapter wird mit dem RX-Kontakt auf dem Arduino

verbunden und anders herum. Somit können beide Senden und Empfangen. [43]

Zusätzlich muss noch ein Potentialausgleich stattfinden. Dazu verbindet man jeweils

einen „GND“-Kontakt auf dem Arduino mit dem „GND“-Kontakt auf dem Adapter.

Ohne diesen Ausgleich würden die Daten verfälscht und könnten nicht mehr gelesen

werden.

Entwicklung eines Türüberwachungsprototyps 39

Da der Prototyp in vorliegender Arbeit über eine eigene Stromversorgung verfügt, die

den Arduino mit versorgt, muss keine zusätzliche Stromversorgung angeschlossen wer-

den. Der genutzte Adapter verfügt trotzdem über einen 5,0 V und einen 3,3 V Kontakt,

der den Arduino auch versorgen kann, sollte keine externe Stromversorgung verfügbar

sein. Dazu wird die Stromversorgung des Adapters mit dem Pin „VCC“ verbunden. [51]

Wenn der Arduino korrekt verbunden ist und die Software installiert wurde, kann nun

Arduino IDE gestartet werden. Nach dem Start sollte sich ein Textfenster öffnen, in dem

zunächst einmal das spätere Board konfiguriert werden muss.

Die Konfiguration wird über den Reiter Werkzeuge gesteuert. In ihm muss neben der

Platine auch der Prozessor ausgewählt werden. Der Arduino Pro Mini besitzt schon einen

eigenen Eintrag und wird als „Arduino Pro oder Pro Mini“ gelistet. Sobald man diese

Option auswählt, kann man den Prozessor bestimmen. Auf dem für dieses Projekt ver-

wendeten Arduino befindet sich ein ATMega328 mit 3,3 V Versorgungsspannung. Aus

diesem Grund wird im Menü „ATMega328 (3.3V, 8 MHz)“ ausgewählt. Zum Schluss

muss in der Entwicklungsumgebung noch der Port, an dem der TTL-USB-Adapter an-

geschlossen ist, angegeben werden. Dieser Eintrag ist unter Werkzeuge -> Port auswähl-

bar. Danach kann mit der Entwicklung der Firmware begonnen werden. [32]

Der Arduino soll in einem bestimmten Rhythmus die Sensoren nach einer Bewegung

abfragen und je nach Schwellwert der Sensoren entscheiden, ob der Raspberry Pi 2

gestartet werden soll. Innerhalb dieses Rhythmus ist es wichtig, so wenig Strom wie

möglich zu verbrauchen. Deshalb wird der Arduino nur für Millisekunden gestartet und

sofort nach der Überprüfung der Sensoren wieder in einen Schlafmodus versetzt. Für die-

sen Schlafmodus muss eine zusätzliche Bibliothek geladen werden. Die Firma Rocket

Scream stellt eine kostenlose Bibliothek namens Low-Power zur Verfügung. Diese wird

über das Reitermenü „Sketch -> Incluse Library -> Add .ZIP Library..“ zur IDE hinzu-

gefügt. Danach kann man über den Button „Sketch -> Incluse Library -> Low-Power-

master“ den Quellcode von LowPower einbinden. [33]

Die Firmware des Arduino ist in drei Abschnitte eingeteilt. Im ersten Abschnitt, der

Programmkopf genannt wird, werden neben dem Einbinden der LowPower-Bibliothek

auch die später zu verwendenden Variablen festgelegt. Jedem Sensor wird dazu eine

Zahl oder eine Kombination aus dem Buchstaben A und einer Zahl zugeteilt. Befindet

sich ein A in der Variable, handelt es sich um einen analogen GPIO Pin. Bei einer Va-

riablen, die nur aus einer Zahl besteht, spricht man hingegen von digitalen GPIO Pins.

Das A kann auch bei analogen GPIO Pins weggelassen werden. Es verdeutlicht aber den

Unterschied zwischen analogen und digitalen Signalquellen.

Entwicklung eines Türüberwachungsprototyps 40

Neben den Pins werden die für die spätere Bewegungserkennung notwendigen Variablen

festgelegt. Der PIR-Sensor ist ein digitaler Sensor und verfügt nur über ein „HIGH“ oder

„LOW“. In diesem Fall wird nur ein Wert benötigt. Die anderen beiden Sensoren überge-

ben analoge Werte. Um diese auszuwerten, wird ein Schwellwert festgelegt. Übersteigt

ein Sensor diesen Wert, kommt es zur Auslösung eines Alarms. Somit kann mit der Soft-

ware die Sensibilität des Sensors gesteuert werden. Zusätzlich zum Schwellwert kommt

beim Ultraschallsensor noch ein Standardwert hinzu. Er erkennt Objekte, indem er den

Standardwert mit dem momentan gemessenen Wert vergleicht. Liegt der Unterschied

oberhalb des Schwellwerts, wird ein Objekt als erkannt angegeben.

Nach der Deklaration der Sensor abhängigen Variablen wird der Countdown und des-

sen Standardwert definiert. Er ist abhängig von den Messungen, die der Arduino pro

Sekunde durchführt, und steuert damit das Relais des Spannungswandlers. Im Moment

sind zwei Messungen pro Sekunde eingestellt. Soll der Countdown 20 Sekunden betra-

gen, muss diese Zahl verdoppelt werden, da der Arduino nach jedem Messvorgang den

Wert dekrementiert. Zum Schalten des Relais ist es außerdem notwendig, noch den Pin

anzugeben, der mit dem Spannungswandler verbunden ist. Diesen Wert speichert die

Variable „powerpi“.

Der letzte Teil des Programmkopfes entscheidet, in welchem Modus der Arduino betrie-

ben wird. Es kann über den genutzten Sensor entschieden werden und ob der Arduino

gleichzeitig stetig Werte über die serielle Verbindung schicken oder ob der Stromspar-

modus aktiviert werden soll.

Nach dem Programmkopf folgen die zwei anderen Teile des Programms. Diese sind

durch die Funktion „setup()“ und „loop()“ erkennbar. In „setup()“ werden die nur einmal

aufzurufenden Funktionen geschrieben, in diesem Fall die Initialisierung der Eingänge,

wogegen in „loop()“ der Programmcode jedes Mal wiederholt wird, sobald er ausgeführt

wurde. Deshalb überprüft „loop()“ ständig die Werte des ausgewählten Sensors und gibt

sie bei Bedarf aus. Sollte kein Bedarf bestehen wird der Arduino in der halben Sekunde

zwischen den Messungen ausgeschaltet.

Quellcode 26: Arduino Firmware# i n c l u d e <LowPower . h>

/ / V a r i a b l e n d e k l a r i e r e ni n t p i r = 9 ;i n t p i r _ c u r r e n t ;i n t r a d a r = A0 ;i n t r a d a r _ c u r r e n t = 0 ;i n t r a d a r _ t h r e s h o l d = 800 ;i n t s o n a r = A1 ;i n t s o n a r _ d e f a u l t ;i n t s o n a r _ c u r r e n t ;

Entwicklung eines Türüberwachungsprototyps 41

/ / Z e i t nach dem d e r R a s p b e r r y P i 2 w ie de r a u s g e s c h a l t e t wi rd/ / Der Arduino s c h l a e f t 500ms . Desha lb werden j e d e Sekunde zwei Sekunden abgezogen .i n t c o u n t d o w n _ d e f a u l t = 20 * 2 ;i n t countdown = 0 ;i n t p o w e r r p i = 1 0 ;

i n t s e n s o r = 0 ; / / 0 = PIR , 1 = Sonar , 2 = Radari n t debug = 0 ; / / 0 = Stromsparmodus ohne Ausgabe , 1 = Ausgabe ohne Stromsparmodus

/ / P i n s f e s s t l e g e nvo id s e t u p ( )

s w i t c h ( s e n s o r ) c a s e 0 :

pinMode ( p i r , INPUT ) ;b r e a k ;

c a s e 1 :pinMode ( sona r , INPUT ) ;d e l a y ( 2 0 0 ) ;s o n a r _ d e f a u l t = s o n a r _ c u r r e n t = ana logRead ( s o n a r ) ;b r e a k ;

c a s e 2 :pinMode ( r a d a r , INPUT ) ;b r e a k ;

S e r i a l . b e g i n ( 9 6 0 0 ) ;

/ / Fo lgende F u n k t i o n wird i n e i n e r D a u e r s c h l e i f e a u s g e f u e h r tvo id loop ( )

/ / Z u e r s t wi rd d e r Countdown u e b e r p r u e f ti f ( countdown == 0)

d i g i t a l W r i t e ( power rp i , LOW) ;e l s e i f ( countdown >= 0)

/ / Wenn d e r Countdown a k t i v i e r t wurde s o l l e r b e i jedem A uf ru f d e r F u n k t i o n loop ( ) a b l a u f e ncountdown−−; / / Die F u n k t i o n wird a l l e 500ms a u f g e r u f e n .d i g i t a l W r i t e ( power rp i , HIGH ) ;

/ / A k t u e l l e Messwer te a b r u f e n/ / Messwer te u e b e r p r u e f e n/ / S c h w e l l w e r t Sonar = 20cm/ / S c h w e l l w e r t Radar = 600s w i t c h ( s e n s o r )

c a s e 0 :p i r _ c u r r e n t = d i g i t a l R e a d ( p i r ) ;i f ( p i r _ c u r r e n t == HIGH)

countdown = c o u n t d o w n _ d e f a u l t ;b r e a k ;

c a s e 1 :s o n a r _ c u r r e n t = ana logRead ( s o n a r ) ;i f ( ( s o n a r _ d e f a u l t − s o n a r _ c u r r e n t ) > 20)

countdown = c o u n t d o w n _ d e f a u l t ;b r e a k ;

c a s e 2 :r a d a r _ c u r r e n t = ana logRead ( r a d a r ) ;i f ( r a d a r _ c u r r e n t > 600)

countdown = c o u n t d o w n _ d e f a u l t ;b r e a k ;

s w i t c h ( debug ) c a s e 0 :

/ / Delay b i s zum n a e c h s t e n A uf ru f von loop ( ) ./ / Da d e r M i k r o c o n t r o l l e r i n d e r Z e i t r u h t kann e r s c h l a f e nLowPower . powerDown ( SLEEP_500MS , ADC_ON, BOD_OFF ) ;b r e a k ;

c a s e 1 :/ / DebuggingS e r i a l . f l u s h ( ) ;

Entwicklung eines Türüberwachungsprototyps 42

S e r i a l . p r i n t ( " PIR S t a t u s : " ) ;S e r i a l . p r i n t ( p i r _ c u r r e n t ) ;S e r i a l . p r i n t ( " , " ) ;S e r i a l . p r i n t ( " Sonar : " ) ;S e r i a l . p r i n t ( s o n a r _ c u r r e n t ) ;S e r i a l . p r i n t ( " cm , Sonar−d e f a u l t : " ) ;S e r i a l . p r i n t ( s o n a r _ d e f a u l t ) ;S e r i a l . p r i n t ( " cm , " ) ;S e r i a l . p r i n t ( " , " ) ;S e r i a l . p r i n t ( " Radar : " ) ;S e r i a l . p r i n t ( r a d a r _ c u r r e n t ) ;S e r i a l . p r i n t ( " , " ) ;S e r i a l . p r i n t ( " Countdown : " ) ;S e r i a l . p r i n t l n ( countdown ) ;d e l a y ( 5 0 0 ) ;b r e a k ;

Das Programm wird nach der Entwicklung durch den Button Verifizieren kompiliert. Um

den Programmcode in den Mikrocontroller zu laden, muss gleichzeitig der Button Hoch-

laden und der Reset-Knopf am Mikrocontroller betätigt werden. Meist werden mehrere

Versuche benötigt, bis das erfolgreiche Hochladen des Programmcodes in der Arduino

IDE bestätigt wird. [32]

Der abschließende Test mit der Firmware verlief problemlos. Alle Sensoren wurden

erkannt und der Spannungswandler wurde durch den Arduino Mikrocontroller geschal-

tet.

6.4. Planung und Ausführung der Stromversorgung

Die autarke Stromversorgung ist eines der Kernprobleme, die es zu lösen gilt. Mit der

Wahl der Basisplattform Raspberry Pi 2 muss sowohl ein starker Sonnenkollektor als

auch ein starker Akku verbaut werden, um die benötigte Energie lang genug zu liefern.

Der Standort wird dabei eine wichtige Rolle spielen, und es muss sich erst zeigen, ob ein

Einsatz eines Sonnenkollektors im Gebäude überhaupt möglich ist.

6.4.1. Ladesteuerung

Jedes zuverlässige autarke System besitzt einen Akku, der über erneuerbare Energien

geladen wird. Ein Akku ist deshalb notwendig, da die erneuerbaren Energien, vor allem

Wind- und Solarkraft, nicht 24 Stunden zur Verfügung stehen. Der in diesem Prototyp

eingesetzte LiPo lädt sich während bestimmter Phasen auf und gibt seinen Strom kon-

tinuierlich über den ganzen Tag verteilt ab. Somit ist das System 24 Stunden lang ein-

satzbereit, wenn in den Ladephasen genug Strom durch erneuerbare Energien erzeugt

werden kann.

Entwicklung eines Türüberwachungsprototyps 43

Durch die begrenzte Größe des Systems, das an der Tür befestigt werden soll, kommen

nur Sonnenkollektoren als Energieerzeuger infrage. Voraussetzung dieser Kollektoren

ist ein Befestigungsort, der in der Sonne liegt. Dies ist im Gebäude schwieriger zu reali-

sieren als an Haustüren, die sich im Freien befinden. Wie groß der Unterschied zwischen

einem Einsatz im Freien und im Gebäude ist, wird sich am Ende noch herausstellen.

Um die gewonnene Sonnenenergie zu nutzen, braucht das System eine Ladesteuerung,

die den Akku lädt und entlädt. Nach kurzer Recherche wurden zwei Firmen gefunden,

die für den Open-Source-Bereich eine Ladesteuerung bereitstellen. Die erste Firma heißt

Sparkfun Electronics und bietet einen MMax Power Point Tracking (MPPT) Solar Char-

ger an. Dieser kann durch Sonnenkollektoren betrieben werden, die eine Spannung von

6 bis 20 V haben. Der normale maximale Ladestromfluss der Batterie beträgt 450 mA.

Er kann aber bis auf 2 A hoch geregelt werden, wenn der LiPo auch mindestens 2 A

speichern kann. [46] MPPT Ladesteuerungen sind besonders effizient, da sie je nach

Spannung, Sonneneinstrahlung und Temperatur des Sonnenkollektors, den optimalen

Punkt finden, um die meiste Energie aus dem Kollektor zu beziehen. Somit ist zu jeder

Zeit die optimale Ausnutzung der möglichen Sonnenenergie gewährleistet. [14]

Der zweite Solar Charger von Adafruit verspricht trotz nicht eingesetzter MPPT- Tech-

nologie eine fast identische Leistung, ohne die etwas höheren Kosten einer richtigen

MPPT-Ladesteuerung. Zusätzlich lässt sich bei diesem Board der Akku mithilfe eines

schon installierten USB-Mini-Typ-B-Anschlusses laden. Damit erweitert sich der Ein-

satzbereich des Prototyps auch auf Anwendungsgebiete ohne Sonnenlicht. Die Steue-

rung ist standardmäßig auf einen Ladestromfluss von maximal 500 mA eingestellt und

kann durch den Tausch eines Widerstandes auf 1 A erhöht werden. Ein großer Vorteil ist

die Funktion „Smart load sharing“. Sie versorgt das System direkt mit Strom vom Son-

nenkollektor, ohne dabei gleichzeitig den Akku durch Auf- und Entladen zu belasten.

Das schont diesen und ermöglicht eine auf die Jahre gesehene längere Haltbarkeit des

LiPo. [49]

Trotz der besseren Effizienz der MPPT-Ladesteuerung wurde in diesem Projekt die Steue-

rung von Adafruit eingesetzt. Für diese Wahl sprach vor allem die Möglichkeit für den

Anwender, das System an schwierigen Orten leicht via USB zu betreiben, ohne sich

Gedanken über die maximale Spannung zu machen. Bei größeren Projekten sollte den-

noch nicht auf eine MPPT-Steuerung verzichtet werden, um möglichst viel Energie zu

erzeugen.

Entwicklung eines Türüberwachungsprototyps 44

6.4.2. Sonnenkollektor

Die Ladesteuerung wird zum großen Teil durch einen Sonnenkollektor versorgt. Er läuft

mit 6 V und hat eine Größe von 15,5 x 23 cm mit einem maximalen Stromfluss von 500

mA. [19] Zusätzlich werden zwei kleinere von Facilla hergestellte Sonnenkollektoren

eingesetzt. Sie bringen maximal 166 mA bei einer Größe von 11,5 x 7,0 cm. [20] Somit

sollten theoretisch 832 mA bei 6 V zur Verfügung stehen.

Der Verbund an Sonnenkollektoren wurde außen am Fenster, hinter dem Fenster und

zwei Meter entfernt vom Fenster getestet, um die Einsatzszenarien an der Haustür, im

Haus und am Fenster zu simulieren.

Außen wurde ein Stromfluss von maximal 690 mA erzeugt. Je nach Winkel zur Son-

ne konnte mehr Energie gewonnen werden. Durchschnittlich wurden 300 bis 400 mA

erzeugt.

Direkt am Fenster konnten nur noch Stromflüsse bis zu 450 mA erreicht werden, je-

doch nur, wenn der Winkel sehr genau justiert wurde. Das Licht wird dabei von doppelt

verglasten Fenstern besonders gut absorbiert und lässt weniger nutzbares Sonnenlicht

durch.

Bei 2 Meter Entfernung zum Fenster wird kaum noch Energie erzeugt. Die Messwer-

te lagen zwischen 0,5 mA und 50 mA. Spitzen von 250 mA konnten durch Anpassung

des Winkels kurzzeitig erreicht werden.

Die Werte zeigen, dass ein Einsatz der Sonnenkollektoren nur Außen oder in der di-

rekten Nähe eines Fensters Sinn machen. Sobald man sich von diesen weiter entfernt, ist

die Sonnenkraft nicht mehr stark genug, um den Akku in ausreichender Weise aufzula-

den.

6.4.3. Spannungswandler

Im technischen Entwurf sind an verschiedenen Stellen Spannungswandler eingebaut, um

den Spannungsanforderungen der Komponenten gerecht zu werden. Spannungswandler

heben oder senken die Versorgungsspannung der Stromquelle und ermöglichen den Ein-

satz unterschiedlich spezifizierter Komponenten. [45]

Der Arduino Mikrocontroller läuft am effektivsten mit 3,3 V. [17] Um konstant diese

Entwicklung eines Türüberwachungsprototyps 45

Spannung bereitzustellen, wird vor diesen ein LF33CV gesetzt. Dieser wandelt Span-

nung bis maximal 16 V in 3,3 V um. Des Weiteren gibt es noch den Radarsensor. Er ist

der einzige Sensor, der nicht mit 3,3 V läuft und eine Eingangsspannung von 4,75 V bis

5,0 V benötigt. Anders als der LF33CV, der die Spannung im System senkt, muss vor

dem Radarsensor ein Spannungswandler geschaltet werden, der die Spannung anhebt.

Besonders schwierig ist die Versorgung des sensiblen Sensors deshalb, da die Versor-

gungsspannung fast keine Restwelligkeit besitzen darf. [61] Diese würde zu Störungen

bei den Messungen führen.

Der erste für den Prototyp genutzte Spannungswandler „CP07009“ führte zu eben die-

sen verkehrten Messwerten. Nachdem der Fehler durch ein Oszilloskop entdeckt wurde,

kam der Spannungswandler „XL6009“ zum Einsatz. Er hatte im Vergleich zum ersten

Wandler eine viel niedrigere Restwelligkeit. Anschließend funktionierte der Radarsen-

sor einwandfrei.

Abbildung 13: Restwelligkeit von CP07009(links) und XL6009(rechts)

Der letzte eingesetzte Spannungswandler wurde schon bei der Entwicklung der Ardui-

no Firmware vorgestellt. Es handelt sich um den Adafruit Powerboost 1000 Basic mit

schaltbarem Ausgang. Er versorgt das Kamerasystem mit 5,2 V bei maximal 1000 bis

2000 mA. [41] Das reicht für den gleichzeitigen Betrieb des fünf Zoll Displays und des

Raspberry Pi 2 aus.

6.5. Montage des Systems

Das System wurde nach Abschluss der Entwicklung auf eine MDF-Platte befestigt. Die

Sensoren, das Display, die Kamera, die Infrarotleuchtdioden und die Sonnenkollekto-

ren befinden sich auf der Vorderseite. Die restliche Elektronik wurde auf der Rückseite

montiert. Zusätzlich wurden Kippschalter eingebaut, um Komponenten teilweise tem-

Entwicklung eines Türüberwachungsprototyps 46

porär für Messungen zu deaktivieren. Zwei große Abbildungen des Prototyps befinden

sich im Anhang dieser Abschlussarbeit.

Test des Systems 47

7. Test des Systems

Dieses Kapitel thematisiert die durchgeführten Tests des Prototyps. Sie werden am Ende

genutzt, um die aufgestellten Anforderungen zu überprüfen.

7.1. Reaktionszeit des Kamerasystems

Eine eingangs erwähnte Anforderung definierte eine Reaktionszeit des Kamerasystems

unter zehn Sekunden. Damit ist die Zeit gemeint, die der Raspberry Pi 2 benötigt, bis

er kalt gestartet ein Bild auf einem Server anzeigt. Mehrere Messungen dieser Zeit ha-

ben ergeben, dass das Ziel knapp erreicht wurde. Die Toleranz der gemessenen Zeiten

liegt zwischen 9,60 bis 10,40 Sekunden. Die meiste Zeit wird dabei, nach Beobachtung

mehrerer Starts, für den Aufbau der WLAN-Verbindung benötigt. Alternative Übertra-

gungswege wie z.B. Ethernet würden die Zeit noch einmal deutlich verringern, dafür

aber die Unabhängigkeit des Systems gegenüber der Verkabelung brechen. Bluetooth

würde zwar über einen schnelleren Verbindungsaufbau verfügen, wäre aber dennoch im

Moment noch keine Alternative, da es momentan über keine ausreichende Verbreitung

bei älteren Geräten verfügt. [24] Dies könnte sich in den nächsten Jahren ändern.

Einen weiteren großen Teil der Zeit verbrachte der Raspberry Pi mit der Initialisierung

der SD-Karte. Während andere Systeme ihre Firmware auf internen Speichern ablegen,

liegt beim Raspberry Pi die Firmware auf der SD-Karte. Um an diesen zu gelangen,

muss zuerst die SD-Karte initialisiert werden. Diese Initialisierung lässt sich als einzige

nicht optimieren, dennoch ist die erzielte Zeit des Raspberry Pi 2 sehr erstaunlich und

erfüllt die zweite Anforderung.

7.2. Stromverbrauch

Der Stromverbrauch eines Akku betriebenen Systems entscheidet über dessen Laufzeit.

Schon kleine Einsparungen in diesem Bereich können die Zeit erheblich beeinflussen.

Aus diesem Grund wurde in vorliegender Arbeit viel Wert auf Energie sparende Lösun-

gen gelegt und der Verbrauch jeder einzelnen Komponente gemessen. Um einen ver-

gleichbaren Wert zu anderen Komponenten zu bekommen, wurde das Multimeter direkt

am Akku befestigt. Dabei ist der tatsächliche reale Verbrauch in anderen Testbedingun-

gen etwas niedriger, da die vorgesetzten Spannungswandler ebenfalls etwas Strom ver-

brauchen. Für das System sind aber die realen Werte wichtiger.

Test des Systems 48

7.2.1. Stromverbrauch des Raspberry Pi 2

Alle gemessenen Werte variieren zwischen ± 10 mA. Auffällig ist der hohe Stromver-

brauch mit angeschaltetem Display. Dabei geht der Spannungswandler schon an die

Grenzen des Möglichen. Ein Betrieb ohne Display ist deshalb zu empfehlen.

Sehr gut sind die Werte im Stand-by. Mit nur 0,15 mA verbraucht der Spannungswandler

zusammen mit der Ladesteuerung sehr wenig Strom und schont damit den Akku.

Tabelle 5: Stromverbrauchsmesswerte des Raspberry Pi 2Raspberry Pi 2 - Status StromverbrauchAusgeschaltet 0,15 mAAngeschaltet (min) 380 mAAngeschaltet (typ) 866 mAAngeschaltet (max) 945 mAAngeschaltet mit Display (min) 647 mAAngeschaltet mit Display (typ) 1250 mAAngeschaltet mit Display (max) 1342 mA

7.2.2. Stromverbrauch des Arduino Mikrocontroller

Der Arduino Mikrocontroller verbraucht, richtig konfiguriert, sehr wenig Strom und ist

damit ideal für den 24-Stunden-Betrieb. Die Werte beziehen sich dabei auf die realen

Bedingungen mit Ladesteuerung und Spannungswandler. Somit ist der tatsächliche Ver-

brauch noch einmal deutlich geringer.

Tabelle 6: Stromverbrauchsmesswerte des Arduino MikrocontrollersStatus StromverbrauchAusgeschaltet 0,53 mAArduino ohne Stromsparmodus 4,33 mAArduino mit Stromsparmodus 0,66 mAPyroelektrischer Sensorohne Signal

0,04 mA

Pyroelektrischer Sensormit Signal

0,85 mA

7.2.3. Ergebnis der Strommessungen

Die gemessenen Werte geben einen gewissen Überblick darüber, wie viel Energie das

System pro Tag verbraucht. Geht man von durchschnittlich einer Stunde Betriebsdauer

Test des Systems 49

des Kamerasystems aus in Verbindung mit einem 24-Stunden-Standby Mikrocontrol-

ler, werden pro Tag ca. 1 A verbraucht. Die Messwerte der Sonnenkollektoren ergaben,

dass bei direkter Sonne ungefähr 50 Prozent der versprochenen Leistung pro Stunde zur

Verfügung stehen. Platziert man das System draußen oder nahe am Fenster, können pro

Stunde 300 bis 400 mA bei 6 V erzeugt werden. Somit kann das System die benötig-

te Energie für den Tag nach 3 bis 4 Sonnenstunden bereitstellen. Umwelteinflüsse wie

dichte Wolken oder dunkle Winter können das System an ihre Grenzen bringen. Deshalb

wurde bewusst ein großer 6000 mA Akku verbaut, um auch Tage ohne Sonnenlicht zu

überbrücken. Letztendlich kann nur ein richtiger Test über mehrere Monate Aufschluss

über die Laufzeit geben, da zu viele Faktoren einen Einfluss auf diese haben. Die im

Sommer gemessenen Werte reichen jedoch aus, um das System 24 Stunden lang laufen

zu lassen. Ob dies auch im Winter der Fall ist, wird sich noch zeigen.

7.3. Bildqualität in unterschiedlichen Lichtumgebungen

Die Bildqualität der Kamera ist bei einer Auflösung von 1920 x 1080 Pixeln sehr gut. So-

wohl am Tag als auch bei Nacht werden scharfe Aufnahmen von Gesichtern gemacht, die

eine Weiterverarbeitung für eine Personenerkennungssoftware möglich machen. Grund

dafür ist die infrarotfähige Kamera des Raspberry Pi, die zusätzlich die Helligkeit nach

regelt. Wird sie durch eine Infrarotleuchtdiode unterstützt, kann sie auch bei schlechten

Sichtverhältnissen gute Aufnahmen machen.

Der Test der Kamera stellt vier verschiedene Szenarien da, jeweils mit einer Person im

Bild. Der Abstand der Person zur Kamera beträgt ca. 1 Meter. Aufgenommen wurde das

zum Server gestreamte Bild.

7.3.1. Aufnahmen bei Tageslicht

Die Kamera kann auch stark belichtete Personen aufnehmen indem sie die Lichtempfind-

lichkeit des Bildsensors reguliert. Auffällig sind die Veränderung von dunklen Stellen,

die durch den fehlenden Infrarotfilter leicht verändert wurden.

Test des Systems 50

Abbildung 14: Person bei Tageslicht

Zum Vergleich wurde auch die andere Ansicht aufgenommen. Bei direkter Sonnenein-

strahlung können keine Gesichter mehr erkannt werden.

Abbildung 15: Person bei starkem Gegenlicht

7.3.2. Aufnahmen bei schwachem Licht

Zusätzlich zum Tageslicht wurden auch Aufnahmen mit künstlichem Licht und in voll-

kommener Dunkelheit aufgenommen.

Abbildung 16: Person bei künstlichem Licht

Die Kamera nimmt bei künstlichem Licht sehr gute Bilder auf. Nur die in diesem Bild

verwendete LED-Deckenlampe verursachte ein leichtes Flimmern, welches aber keine

Auswirkung auf die Personenerkennung hat.

Test des Systems 51

Abbildung 17: Person bei vollkommener Dunkelheit

In vollkommener Dunkelheit können Personen nur noch in einem Meter Abstand erkannt

werden. Die verbauten Infrarotleuchtdioden sind für die Ausleuchtung des kompletten

Zimmers zu schwach.

7.4. Überprüfung der Anforderungen

Nachdem der Prototyp fertiggestellt wurde, werden nun die gewonnenen Ergebnisse aus

diesem Kapitel mit den in der Einleitung aufgeführten Anforderungen verglichen.

7.4.1. Anforderung 1

Die erste Anforderung einer HD-Bildqualität der Kamera konnte durch die Verwen-

dung der Infrarotkamera erreicht werden. Es ist sogar möglich, durch den performanten

Raspberry Pi 2 ein Full-HD-Bild von der Kamera auf dem Server anzuzeigen.

7.4.2. Anforderung 2

Anforderung zwei forderte einen Start in weniger als zehn Sekunden. Das Kamerasystem

und dessen Firmware wurden während der Entwicklung so gut optimiert, dass ein Start in

zehn Sekunden möglich ist und Besucher rechtzeitig zur Identifizierung gefilmt werden

können.

7.4.3. Anforderung 3

Die unabhängige Stromversorgung ohne externe Kabel wurde teilweise erfüllt. Solange

das System und seine Sonnenkollektoren an einer Außentür oder direkt an einem Fens-

ter befestigt werden, wird genug Strom für einen 24-Stunden-Betrieb erzeugt. Innerhalb

eines Gebäudes wird das Licht aber zu stark gedämpft, sodass eine externe Stromversor-

gung daher unumgänglich ist.

Test des Systems 52

7.4.4. Anforderung 4

Die Bewegungserkennung des Prototyps arbeitet zuverlässig und kann Objekte mit ei-

nem Abstand von 8 bis 9 Metern entdecken. Damit bietet es dem Kamerasystem genug

Zeit zum Booten.

7.4.5. Anforderung 5

Durch die Wahl der WLAN-Funkschnittstelle und dem Programm Netcat ist eine offe-

ne Schnittstelle zur Übertragung gegeben. Damit können alle Linux-, Mac- und Win-

dowssysteme den Stream empfangen und weiterverarbeiten. Selbst Android unterstützt

durch Drittanbieter Netcat als Netzwerkübertragungsprogramm. [7]

7.4.6. Anforderung 6

In der sechsten Anforderung wurde eine gute Aufnahmequalität auch bei schlechten

Sichtverhältnissen vorausgesetzt. Dies konnte durch eine Infrarotleuchtdiode und einer

infrarotfähigen Kamera erfüllt werden.

7.4.7. Ergebnis

Der abschließende Test zeigte, dass fünf von sechs Anforderungen vollständig erfüllt

werden konnten. Einzig die unabhängige Stromversorgung bereitet unter bestimmten

Bedingungen Probleme. Diese können teilweise durch die richtige Positionierung des

Systems behoben werden.

Fazit 53

8. Fazit

Das Ziel dieser Thesis war die Entwicklung eines Türüberwachungsprototyps, der in der

Lage sein sollte, in unterschiedlichen Lichtverhältnissen gute Bilder aufzunehmen und

diese an einen Server weiterzuschicken. Dabei sollte der Stromverbrauch so gering wie

nur möglich ausfallen, sodass ein 24-Stunden-Betrieb mit erneuerbaren Energien ge-

währleistet werden kann. Das Ergebnis der Arbeit zeigt, dass ein solches System in der

Realität funktioniert. Zwar gibt es bei der Energieversorgung durch Sonnenkollektoren

Einschränkungen, das System entspricht aber ansonsten den gegebenen Anforderungen.

Der verbaute Mikrocontroller verbraucht mitsamt seines Sensors und dem Spannungs-

wandler des Raspberry Pi nicht mehr als 1 mA. Somit können die Sonnenkollektoren

das System im Stand-by auch im Inneren eines Gebäudes gut versorgen. Nur der hohe

Stromverbrauch des Raspberry Pi 2 hält sie davon ab.

Neue Energie sparende Prozessoren werden dieses Problem vielleicht zukünftig lösen

können. Bis es soweit ist, müssen Kompromisse seitens der Stromversorgung eingegan-

gen werden. Die Kombination aus einem schnell startenden Kamerasystem mit einem

stromsparenden Mikrocontroller mit Bewegungssensor löst das Problem zumindest teil-

weise.

Neben dem Prozessor kann auch die Steigerung der Effizienz der Sonnenkollektoren ei-

ne Möglichkeit sein, um das Energieproblem zu lösen. Forscher haben dazu erst kürzlich

einen neuen Weltrekord mit einer Solarzelle aufgestellt, die einen Wirkungsgrad von 46

Prozent erreichte. [44] Damit liegt sie deutlich über der Effizienz aktueller Solarzellen

und könnte möglicherweise zukünftig auch Systeme wie den Raspberry Pi im Gebäude

mitversorgen. [62, S.40]

In der Übertragung von Videostreams ist die Technologie schon deutlich weiter ent-

wickelt. Wie gezeigt wurde, kann ein Video in Full-HD mit 15 Bildern pro Sekunde pro-

blemlos übertragen werden. Es wird in der Zukunft noch höher aufgelöste Videostreams

geben. Zumindest wurde aber der Punkt, an dem Türkameras für die Personenerkennung

wenig geeignete Videos in VGA-Qualität übertragen haben, bereits von diesem Prototyp

und den Produkten wie dem DoorBird-System der Firma 1000eyes GmbH überschrit-

ten.

Literatur 54

Literatur

[1] Adam. Streaming video using gstreamer. http://www.raspberry-

projects.com/pi/pi-hardware/raspberry-pi-camera/streaming-

video-using-gstreamer. Stand: 12-10-2015.

[2] Guillermo A. Amaral. Lightweight raspberry pi distribution based on buildroot.

https://github.com/gamaral/rpi-buildroot. Stand: 07-10-2015.

[3] Charles Bell. Beginning Sensor Networks with Arduino and Raspberry Pi. Apress,

2013.

[4] Hans-Joachim Berndt. Geschwindigkeits-messung mit arduino. http://

hjberndt.de/soft/radar/index.html. Stand: 15-10-2015.

[5] Tyler Cooper. 3.3v conversion. https://learn.adafruit.com/arduino-

tips-tricks-and-techniques/3-3v-conversion. Stand: 22-10-2015.

[6] Klaus Dembowski. Raspberry Pi – Das technische Handbuch. Springer Fachme-

dien Wiesbaden, 2015.

[7] Pavel Derendyaev. Simple netcat implementation for android. https://github.

com/dddpaul/android-SimpleNetCat. Stand: 30-10-2015.

[8] Mike Gleason. ncftpput - internet file transfer program for scripts. http://www.

ncftp.com/ncftp/doc/ncftpput.html. Stand: 11-10-2015.

[9] Joshua Henderson. Wireless on raspberry pi with buildroot. http://www.

digitalpeer.com/blog/wireless-on-raspberry-pi-with-buildroot.

Stand: 07-10-2015.

[10] Nico Jurran. König blauzahns schlachtplan neue roadmap für bluetooth smart –

mit mesh-netzwerk, besseren beacons und hörgeräten. http://www.heise.de/

ct/ausgabe/2015-22-Neue-Roadmap-fuer-Bluetooth-Smart-mit-Mesh-

Netzwerk-besseren-Beacons-und-Hoergeraeten-2827725.html. Stand:

15-10-2015.

[11] Matthias Kettner. Ssh anmeldung ohne passwort. https://mathias-kettner.

de/lw_ssh_anmeldung_ohne_passwort.html. Stand: 11-10-2015.

[12] Alexander Kisselmann. Der beste wlan usb-adapter für deinen raspberry

pi 2. http://powerpi.de/der-beste-wlan-usb-adapter-fuer-deinen-

raspberry-pi-2/. Stand: 07-10-2015.

[13] Lasall. Makefile. https://wiki.ubuntuusers.de/makefile. Stand: 07-10-

2015.

Literatur 55

[14] Sergiu Oprea Mihnea Rosu-Hamzescu. Practical guide to implementing solar pa-

nel mppt algorithms. http://ww1.microchip.com/downloads/en/AppNotes/

00001521A.pdf. Stand: 15-10-2015.

[15] MIPI Alliance. Camera interface specifications. http://mipi.org/

specifications/camera-interface. Stand: 10-09-2015.

[16] Rainer Müller. Die physik des gehens als unterrichtsgegenstand.

https://www.tu-braunschweig.de/Medien-DB/ifdn-physik/gehen-

und-laufen.pdf. Stand: 22-10-2015.

[17] Jan David Neuy. Arduino low power - how to run atmega328p for a year on coin

cell battery. http://www.home-automation-community.com/arduino-low-

power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/.

Stand: 25-10-2015.

[18] o.V. 5 inch resistive touch screen lcd, hdmi interface, designed for raspber-

ry pi. http://eckstein-shop.de/5-inch-Resistive-Touch-Screen-LCD-

HDMI-interface-Designed-for-Raspberry-Pi. Stand: 14-10-2015.

[19] o.V. 6v 3.5w 500ma mini solar panel ladegerät solar power panel für telefon

handy tablets und spielzeug. http://www.amazon.de/500mA-Ladegerät-

Telefon-Tablets-Spielzeug/dp/B00WG14AJS. Stand: 25-10-2015.

[20] o.V. 6v solarpanel solarmodul solarzelle 1w 166ma zur aufladung.

http://www.amazon.de/Solarpanel-Solarmodul-Solarzelle-166mA-

Aufladung/dp/B00LEBVEVS. Stand: 25-10-2015.

[21] o.V. Api. http://www.doorbird.com/de/api. Stand: 25-10-2015.

[22] o.V. Arduino pro mini. https://www.arduino.cc/en/Main/

ArduinoBoardProMini. Stand: 25-10-2015.

[23] o.V. Atmega48a/pa/88a/pa/168a/pa/328/p. http://www.atmel.com/images/

atmel-8271-8-bit-avr-microcontroller-atmega48a-48pa-88a-88pa-

168a-168pa-328-328p_datasheet_complete.pdf. Stand: 15-10-2015.

[24] o.V. Bluetooth low energy / bluetooth smart (4.0 / 4.1 / 4.2). http://www.

elektronik-kompendium.de/sites/kom/1805171.htm. Stand: 30-10-2015.

[25] o.V. Camera. https://www.raspberrypi.org/documentation/hardware/

camera.md. Stand: 14-10-2015.

[26] o.V. Doorbird. https://www.doorbird.com/de/. Stand: 13-09-2015.

[27] o.V. Download the arduino software. https://www.arduino.cc/en/Main/

Softwarei. Stand: 30-10-2015.

Literatur 56

[28] o.V. Face recognition with opencv. http://docs.opencv.org/modules/

contrib/doc/facerec/facerec_tutorial.html. Stand: 25-10-2015.

[29] o.V. Funktionsweise und aufbau von ultraschall-sensoren. http:

//www.baumer.com/de-de/services/anwenderwissen/ultraschall-

sensoren/funktionsweise/. Stand: 15-10-2015.

[30] o.V. Gcc. https://wiki.ubuntuusers.de/GCC. Stand: 07-10-2015.

[31] o.V. Genduino. https://www.arduino.cc/en/Main/GenuinoBrand. Stand:

15-09-2015.

[32] o.V. Getting started with arduino on windows. https://www.arduino.cc/en/

Guide/Windows. Stand: 25-10-2015.

[33] o.V. https://www.arduino.cc/en/guide/libraries. http://www.adafruit.com/

products/2030. Stand: 25-10-2015.

[34] o.V. The internet of things: Making sense of the next mega-trend. http://www.

goldmansachs.com/our-thinking/pages/internet-of-things/. Stand:

25-10-2015.

[35] o.V. Ipm-165. http://www.innosent.de/fileadmin/media/dokumente/

datasheets/IPM-165.pdf. Stand: 25-10-2015.

[36] o.V. Kernel modules. https://wiki.archlinux.org/index.php/Kernel_

modules. Stand: 27-10-2015.

[37] o.V. Löten. http://www.elektronik-kompendium.de/sites/grd/0705261.

htm. Stand: 25-10-2015.

[38] o.V. Netcat. https://wiki.ubuntuusers.de/netcat. Stand: 13-10-2015.

[39] o.V. News. http://gstreamer.freedesktop.org. Stand: 13-10-2015.

[40] o.V. Optokoppler / opto-koppler. http://www.elektronik-kompendium.de/

sites/bau/0411091.htm. Stand: 25-10-2015.

[41] o.V. Powerboost 1000 basic. http://www.adafruit.com/products/2030.

Stand: 25-10-2015.

[42] o.V. Raspistill. https://www.raspberrypi.org/documentation/usage/

camera/raspicam/raspistill.md. Stand: 11-10-2015.

[43] o.V. Serial. https://www.arduino.cc/en/Reference/Serial. Stand: 25-10-

2015.

Literatur 57

[44] o.V. Solarzelle mit 46% wirkungsgrad – neuer weltrekord französisch-

deutsche kooperation bestätigt wettbewerbsfähigkeit der europäischen pho-

tovoltaikindustrie. https://www.ise.fraunhofer.de/de/presse-und-

medien/presseinformationen/presseinformationen-2014/solarzelle-

mit-46-prozent-wirkungsgrad-neuer-weltrekord. Stand: 27-10-2015.

[45] o.V. Spannungswandler. http://www.itwissen.info/definition/lexikon/

Spannungswandler-voltage-converter.html. Stand: 25-10-2015.

[46] o.V. Sparkfun sunny buddy - mppt solar charger. https://www.sparkfun.com/

products/12885. Stand: 25-10-2015.

[47] o.V. Technical data sheet photocoupler. http://www.rapidonline.com/pdf/

156422_da_en_01.pdf. Stand: 25-10-2015.

[48] o.V. Tps6109x synchronous boost converter with 2-a switch. http://www.ti.

com/lit/ds/slvs484c/slvs484c.pdf. Stand: 25-10-2015.

[49] o.V. Usb / dc / solar lithium ion/polymer charger - v2. http://www.adafruit.

com/products/390. Stand: 25-10-2015.

[50] o.V. Usb driver installation methods. https://www.silabs.com/Support%

20Documents/TechnicalDocs/an335.pdf. Stand: 25-10-2015.

[51] o.V. Usb to uart bridge. http://www.silabs.com/products/interface/

usbtouart/Pages/usb-to-uart-bridge.aspx. Stand: 25-10-2015.

[52] o.V. Frequenzplan gemäß § 54 tkg über die aufteilung des frequenzbereichs

von 9 khz bis 275 ghz auf die frequenznutzungen sowie über die festle-

gungen für diese frequenznutzungen. http://www.bundesnetzagentur.

de/SharedDocs/Downloads/DE/Sachgebiete/Telekommunikation/

Unternehmen_Institutionen/Frequenzen/Frequenznutzungsplan.pdf?

__blob=publicationFile, 1-05-2015. Stand: 15-10-2015.

[53] Jürgen Quade. Embedded Linux lernen mit dem Raspberry Pi. Springer Berlin

Heidelberg, 2014.

[54] Sascha Ziegelbauer Raimund Girwidz. Infrarotsensoren. http:

//www.didaktikonline.physik.uni-muenchen.de/piko/material/

artikel/infrarotsensoren.pdf. Stand: 15-10-2015.

[55] Rui Santos. Modifying cheap pir motion sensor to work at 3.3v.

http://randomnerdtutorials.com/modifying-cheap-pir-motion-

sensor-to-work-at-3-3v/. Stand: 15-10-2015.

Literatur 58

[56] Patrick Schnabel. Speicherverteilung des raspberry pi ändern (memory

split). https://www.elektronik-kompendium.de/sites/raspberry-pi/

2002121.htm. Stand: 15-10-2015.

[57] stesind. Edimax. https://wiki.ubuntuusers.de/WLAN/Karten/Edimax.

Stand: 07-10-2015.

[58] Dipl.-Ing. (FH) Hendrik Härter Thomas Wolf. Pyrosensor dank abgestrahlter wär-

me lassen sich personen erkennen. http://www.elektronikpraxis.vogel.de/

messen-und-testen/articles/485270/index2.html. Stand: 19-10-2015.

[59] J.A. Watson. Hands-on with the raspberry pi 2. http://www.zdnet.com/

article/hands-on-with-the-raspberry-pi-2/. Stand: 29-10-2015.

[60] Sebastian Weidmann. 24 ghz radarsensor - grundlagen. http:

//www.sebastianweidmann.de/index.php?option=com_content&view=

section&layout=blog&id=17&Itemid=21. Stand: 15-10-2015.

[61] Sebastian Weidmann. Radarsensor 165 inkl. verstärkung (73 db) - arduino me-

ga2560 motion detector example. http://shop.weidmann-elektronik.

de/media/files_public/d8b2f188f3665f85c65fc762de61a095/

Radarsensor165%20Arduino%20Example.pdf. Stand: 25-10-2015.

[62] Voswinckel Wesselak. Photovoltaik - Wie Sonne zu Strom wird. Springer Berlin

Heidelberg, 2012.

[63] Jürgen Wolf. Linux-unix-programmierung. http://openbook.rheinwerk-

verlag.de/linux_unix_programmierung/Kap13-002.htm. Stand: 07-10-

2015.

Anhang 59

A. Anhang

A.1. Vorder- und Rückseite des Prototyps

Abbildung 18: Vorderseite des Prototyps

Anhang 60

Abbildung 19: Rückseite des Prototyps