Post on 09-Oct-2019
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.
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