SmartLock (2): Hardware des Projekts

In diesem Blogeintrag wird die hardwareseitige Umsetzung des SmartLock-Projektes näher beleuchtet. Dafür soll auch auf die Herausforderungen bei der Programmierung des Arduinos eingegangen werden. Zu Beginn dieses Eintrags möchte ich allerdings erst einen Blick auf die verwendeten Hardwarekomponenten werfen und deren Funktion im gesamten System thematisieren. Bei der genutzten Kamera handelt es sich um das Raspberry Pi Kamera Modul in der Version 1.3. Diese kann ein Video mit bis zu 30 Frames bei 1080p aufnehmen, welches vom Raspberry Pi verarbeitet wird. Auf der anderen Seite dieses Projektes steht der Arduino Uno (Blaues Board Abb. 1), mit welchem die restlichen Hardwarekomponenten angesprochen werden. Die Entscheidung fiel auf diese Zweiteilung, da der Arduino eine viel hardwarenähere Programmierung erlaubt. Dies liegt hauptsächlich in zwei Faktoren begründet; einmal erlaubt er durch seine vielen Libraries, die in C++/C/Assembler geschrieben sind, einen schnellen und präzisen Zugriff auf die Hardware, welches durch den Fakt, dass der Arduino in C++ programmiert wird, zusätzlich unterstützt wird. Als zweiter Faktor ist anzuführen, dass der Chip über kein Scheduling verfügt und damit eine planbare Ausführung gewährleistet ist. Nichtsdestotrotz ergaben sich große Herausforderungen bei der Programmierung, auf welche ich an späterer Stelle eingehen werde. Die Kommunikation zwischen den Beiden (Arduino und Pi) findet über eine UART Schnittstelle statt. Diese wird dafür genutzt, einzelne Chars in Byte Form zu übertragen. Bis jetzt wurden folgende Befehle definiert (es werden mit großer Sicherheit weitere folgen, welche hier später ergänzt werden):

Tabelle 1: Serielle Befehle

Als Bindeglied zwischen dem Pi und dem Arduino dient ein sogenannter „Level shifter“. Dieser übernimmt die Umwandlung der Betriebsspannungen und stellt so sicher, dass die 5v des Arduinos den auf 3.3v laufenden Pi nicht beschädigen.

An dieser Stelle soll nun ein genauerer Blick auf die angeschlossene Peripherie des Arduinos geworfen werden. Dazu gehört ein Lichtsensor (rote Platine rechts neben dem Servo Abb. 1), der ein analoges Signal an den Arduino liefert, welches von einer Library decodiert wird (der Chip, der das Signal generiert heißt LM393 und wird für viele Sensoren verwendet. Seine Verbreitung lässt sich darauf zurückführen, dass er gleichzeitig auch ein digitales Signal generiert und sehr kostengünstig ist). Der gewonnene Helligkeitswert wird in einen Algorithmus eingespeist, der die Lichtintensität für den LED-Ring dynamisch bestimmt. Dabei unterscheidet er zwischen den unterschiedlichen Modis dieses Ringes. So wird er dafür genutzt, bei Dunkelheit das Gesicht für die Gesichtserkennung auszuleuchten. Dabei steigt die Helligkeit des Kreises gegenproportional zur Umgebungshelligkeit. Wohingegen die Signale, wie OK (LED-Kreis flackert Grün) oder Failed (LED-Kreis flackert Rot) mit zunehmender Umgebungshelligkeit auch an Helligkeit zunehmen, um somit bei starker externer Lichteinstrahlung sichtbar zu bleiben. Auch wurde an den Arduino ein Piezo-Lautsprecher (links unten blaue Platine Abb. 1) angeschlossen. Dieser dient zur Audiountermalung der auf dem LED Kreis dargestellten Signale. Des Weiteren ist er in der Lage, die Titelmusik von „Game of Thrones“ zu spielen. Als zusätzliche Komponente wird ein Button mit dem Arduino verbunden, dieser hat die Aufgabe die Tür von innen zu öffnen, da das System nach dem Eintreten die Tür automatisch abschließt und somit die Person eingeschlossen wäre.

Abbildung 1: Hardware-Skizze

An dieser Stelle möchte ich auf die bereits angesprochene Problematik mit dem Arduino eingehen. Auch wenn er eine der hardwarenahesten Möglichkeiten ist, ihn mit höheren Programmiersprachen, wie C++ Hardware zu programmieren, so hat er von Haus aus ein Problem. Denn auch er ist, wie der Pi, nicht in der Lage bei komplexen Programmen ein stabiles PWM Signal zu gewährleisten. Dies führt dazu, dass der Servo sich unkontrolliert bewegt und Geräusche von sich gibt. Was für ein professionelles Produkt, wie wir es anstreben, natürlich inakzeptabel ist. Die Lösung für dieses Problem ist es, das PWM Signal nicht vom Chip generieren zu lassen, sondern von einem der zwei Hardwaretimern des ATmega328P (Chip des Arduino uno). Diese relativ unbekannte Möglichkeit erlaubt es, dass Interrupts alle 20ms (der PWM Periode die der Servo SG90 benötigt) getriggert werden und in diesen Interrupts der Duty Cycle für die nächste Periode festgelegt wird. Dadurch, dass die Interrupts vom Hardwaretimer getriggert werden, kann ein nahezu 100 prozentiges Timing erreicht und somit jegliches „Jittern“ unterbunden werden.

Nun soll auf die Stromversorgung eingegangen werden. Diese wird über USB zur Verfügung gestellt. Dabei steht es dem Nutzer frei, ob er das erstellte Produkt mittels Powerbank oder mittels USB Netzteil betreiben möchte, wobei mindesten 3A geliefert werden müssen. Die zwei verbauten Kondensatoren dienen dazu, den Strom zu „glätten“, also eventuelle Spannungsspitzen als Unterspannungen auszugleichen. Kondensatoren werden häufig zum Schutz von empfindlichen Komponenten genutzt.

Abschließend soll noch auf ein spezielles Programmierparadigma eingegangen werden. So wurde die gesamte Arduino Programmierung in diesem Projekt „Non-Blocking“ aufgebaut. Dies bedeutet trotz dem Fakt, dass der Arduino nur über einen Task verfügt, der das Programm in einer Dauerschleife durchläuft, jederzeit die Operationen unterbrochen werden können. Dies kann dadurch erreicht werden, dass Wartezeiten im Programm nicht etwa über ein Anhalten des Tasks realisiert, sondern die einzelnen Ausführungsdauern auf Basis der Systemzeit definiert werden. Dies erhöht zwar die Komplexität bei der Programmierung massiv und führt zu teilweise unschönem Code, zahlt sich aber im Live-Betrieb aus, in welchem es dann ohne Probleme möglich ist, einzelne Ausführungen abzubrechen, um dem Nutzer ein flüssigeres Benutzungserlebnis zu ermöglichen. (Anbei noch ein Artikel, der das Programmierkonzept näher erläutert https://bit.ly/2KMNkZQ). Der erstellte Arduino Quellcode findet sich hier.

Ich hoffe, dass durch diesen Blog ein umfassendes Bild über das komplexe Hardwaresetup dieses Projektes vermittelt werden konnte. Als nächster Blogeintrag wird eine Übersicht über das Backend unseres Servers folgen und damit ein Umschwenken auf die Software eingeleitet.