Der „Wachhund“ Roboter soll eine effizientere Alternative eines echten Wachhundes sein. Der Roboter scannt über einen implementierten Bewegungssensor die Umgebung und löst im Falle einer Bewegung einen Alarm aus.
Dies geschieht über einen angeschlossenen Lautsprecher. Um den Alarm (LEDs, Lautsprecher) zu deaktivieren, muss man sich mit einem vier-stelligen Code authentifizieren. Das Passwort kann nach einer erfolgreichen Authentifikation individuell verändert werden.

Bei unserem Projekt konnten wir alle gewollten Ziele unsererseits umsetzen, dennoch bestünde die Möglichkeit, den Roboter um weitere „Nice-To-Have“ Funktionen zu erweitern, wie z. B. mehr Sounds zu implementieren, ihn zum bewegenden Objekt fahren zu lassen, et cetera pp..
Der Roboter besteht aus drei Hauptbestandteilen, mehr diesbezüglich findet ihr im Überblick.

Baugruppen:

Unserer Roboter besteht aus 2 Quadern à 4 Kanten, welche aus Holzplatten bestehen. Diese Holzplatten haben wir mittels Metallwinkel, Schrauben, Muttern und Heißkleber befestigt.
Das „Herz“ des Roboters besteht aus einem Arduino, welcher im größeren Quader auf einem Breadboard befestigt ist. An diesem Arduino sind alle Komponenten wie z. B. Keypad, Display, etc. angeschlossen.
Das „Auge“ des Roboters ist der kleine Quader, welcher einen Bewegungssensor und zwei LED’s beinhaltet.
Alle einzelnen Bestandteile findet ihr beschriftet in den Abbildungen 2-6.

Abbildung 2: Wachhund Vorne

Abbildung 3: Wachhund von Oben (Großer Kasten)

Abbildung 4: Wachhund von Oben (Kleiner Kasten)

Abbildung 5: Wachhund von hinten (inkl. versteckter Notfallknopf)

Abbildung 6: Wachhund von oben

Aufgaben/Funktionen:

1. Bewegungserkennung (Abb. 2):
Hierbei wird mithilfe eines Bewegungssensors die Umgebung auf Bewegungen gescannt.
Um die Bewegungen zu erkennen, misst der Roboter mittels eines eingebauten Infrarotsensors die naheliegenden Wärmequellen.
Der Hersteller des Bewegungssensors hatte diesem eine Code-Vorlage beigefügt, welche sehr simpel war zu implementieren.
Dieser Code-Abschnitt wird direkt am Anfang des Programms ausgeführt. Anbei findet man die Code-Vorlage in Abbildung 7.

Abbildung 7: Code-Vorlage Bewegungssensor

2. Alarm (Abb. 3):
Hierbei werden LED's und ein Lautsprecher verwendet.
Die LED's erzeugen ein blinkendes Licht, wogegen der Lautsprecher einen Alarm-Sound ausgibt.
Für den Lautsprecher werden zusätzlich ein DF-Player-Mini, sowie eine SD-Karte benötigt, um gezielte MP3-Dateien abspielen zu können.

Weder die LED's noch der DF-Player benötigen eine Library, jedoch mussten wir beim DF-Player einen vorgefertigten Code in unseren Programm implementieren, sodass wir diesen Code erst einmal ausführlich verstehen mussten.


Das Programm des DF-Players basierte auf vielen Funktionen, die sich jeweils beeinflussen. Darüber hinaus gibt es bestimmte Funktionen, mit denen man die Musikwiedergabe spezifisch beeinflussen kann (Beispiel: Liedwechsel, Lautstärke erhöhen/verringern, Play/Pause, etc. )
Um die spezifischen Funktionen aufzurufen, wird verlangt, dass man im seriellen Monitor der Arduino IDE einen bestimmten Buchstaben eingibt
(Play = 'P', Pause = 'p').

AZ-Delivery DF-Player

Aus der gegebenen Anleitung (inkl. Code-Vorlage) konnte man nicht entnehmen wie man die spezifischen Funktionen aufruft.
Im Abschnitt „Technische Herausforderungen“ wird diesbezüglich nochmal darauf eingegangen.

3. Authentifizierung (Abb. 6):
Die Authentifizierung dient zur Deaktivierung des Alarms.
Mehrere Authentifizierungsmöglichkeiten wurden vorgenommen:

1. Keypad (4-stelliger Code)
   
2. Versteckter Knopf (Not-Knopf)
   

Für die Authentifizierung haben wir die Keypad-Library von Mark Stanley und Alexander Brevig benutzt. Keypad Library
Die Knöpfe des Keypads sind anders als beim Display, welches eine i2C-Schnittstelle besitzt, jeweils mit einem digitalen oder (analogen) Pin verbunden.

3.1 Individualisierung des Keypad Codes (Abb. 5):
Wenn man den Alarm deaktiviert hat, ist es einem möglich den Code zu verändern.
Dafür muss man einen weiteren Knopf (Passwort-Knopf) betätigen, welcher es einem ermöglicht das Authentifizierungs-Passwort zu überschreiben.
Am Anfang des Programmablaufs ist schon ein standardmäßiger Code vorgegeben („1234“).
Diesen kann man wie bereits erwähnt nach der erfolgreichen Authentifizierung bearbeiten. Der „alte“ Code („1234“) ist nach der Änderung nicht mehr gültig.

Wenn man bei der Code-Änderung den alten Pin wieder eingibt, wird die Code-Änderung unterbunden und man muss stets wieder einen neuen Code eingeben.

Wenn man den neuen Code identisch zum Easter-Egg Code („#187“) definiert, wird das Easter Egg bei der Eingabe des spezifischen Pins unterbunden.

Der Easter-Egg Code („#187“) ist unveränderbar und fast immer gültig (jedoch nicht zur Authentifikation, außer im genannten Sonderfall.).

4. Kommunikation (Abb. 6):
Das Display ist die Konsolenausgabe des Roboters.
Mit Hilfe des Displays ist es einem möglich die eingetippten Zeichen des Codes, die Richtigkeit des Passwortes, etc. zu sehen.
Beim Display haben wir eine i2C-Schnittstelle verwendet, um die Anzahl der Pins, welche wir an den Arduino für das Display anschließen, zu verringern.
Mit dieser i2C-Schnittstelle konnten wir auch mithilfe einer implementierten Schraube die Helligkeit des Displays steuern.

Für die Schnittstelle und allgemein für das Display benötigten wir eine weitere Library. Die Library nennt sich LiquidCrystal I2C, welche von Frank de Brabander veröffentlicht wurde.
LiquidCrystal I2C Library

Abbildung 8: Schaltplan

Welche Aufgaben wurden bewusst ausgeklammert?

Fortbewegung:
Der Roboter kann sich mit Hilfe von Rädern zum bewegenden Objekt hinfahren. Bei der Fortbewegung würde der Bewegungssensor nicht auslösen, da dieser nicht lediglich die Bewegung scannt, sondern Wärmequellen scannt und dann erst auslöst, wenn diese sich bewegen.

Erweiterungen des Alarms:
Mehrere Lieder die man als Alarm beliebig ändern kann.

1. Anforderungen/Teamarbeit

Besonders bei diesem Projekt war es so, dass wir ein besonders ausgeprägtes handwerkliches Denken als Anforderung besitzen mussten.
Dieses haben wir uns im Laufe der Projektbearbeitung angeeignet, sodass wir die Konstruktion relativ gut hinbekommen hatten.
In Anbetracht dessen, dass wir am Anfang des Projektes nicht sonderlich begabt in diesem Bereich waren, war das Ergebnis dennoch sehr zufriedenstellend.

Durch unsere gelungene Teamarbeit konnten wir teilweise den handwerklichen Teil, dem einem Teampartner überlassen. Folglich konnte sich der andere Teampartner auf den Programmierteil konzentrieren.

2. Technische Herausforderungen
Eine besondere technische Herausforderung (wie bereits in der Abschlusspräsentation erwähnt war, war, dass das Display keinen Text angezeigt hatte. Wir hatten
einiges ausprobiert, Display neu angeschlossen, Arduino geändert, etc.

Im Endeffekt befindet sich an der i2C-Schnittstelle,(siehe Skizze), eine Schraube an der man die Helligkeit regulieren kann.

Die Problemlösung war an der Schraube der i2c-Schnittstelle zu drehen, sodass die Helligkeit nicht mehr so stark ist, wodurch die Buchstaben nicht mehr erkennbar waren.

Ein weiteres Problem bezüglich des Displays war, dass die LED’s des Displays einen Wackelkontakt haben, wodurch man die Zeichen erneut nicht erkennen konnte.
Indem man auf die Platine Druck ausetzt, kann man den Wackelkontakt temporär lösen. Um dies zu erreichen haben wir in den „Wachhund“ ein Loch gebohrt und mithilfe einer Schraube Druck auf das Display ausgeübt. Somit war das Display die größte Herausforderung unseres Projekts.

(1) Die Abbildung 9 zeigt den Schaltplan für die Verbindung des Displays über die i2c-Schnittstelle mit dem Arduino.
(2) Die Abbildung 10 zeigt unsere provisorische Problemlösung für den Wackelkontakt am Display.

Abbildung 9: Schaltplan

Abbildung 10: Display-Problematik

Um Funktionen des DF-Players aufzurufen und um MP3-Dateien abzuspielen muss man im Seriellen Monitor der Arduino IDE, bestimmte Buchstaben eingeben.
Jedoch war das aus der Vorgabe des Herstellers nicht ersichtlich welche Befehele im seriellen Monitor eingegeben werden müssen.
Aufgrund dessen sind wir davon ausgegangen, dass wir bspw. Wörter wie „Play“ oder „Next“ eingeben müssen, was, wie bereits erwähnt, nicht der Fall war.
Im Endeffekt werden die Funktionen mittels einzelner Buchstaben aufgerufen, was daraus resultierte, dass bei der Eingabe von Wörtern wie „Set_Volume“, mehrere Befehle ausgeführt wurden.

Aufgrund der Tatsache, dass die Eingabe der Buchstaben in den seriellen Monitor über den Roboter unerreichbar ist, hatten wir eine Character („data“) - Variable, sowie eine Funktion („befehl()“) hinzugefügt, welche als Ersatz fungieren sollen.

Bei Erreichen eines bestimmten Zustands, wird die „data“-Variable mit einem Buchstaben überschrieben, was mittels der „befehl“-Funktion dazu führt, dass MP3-Dateien abgespielt und lauter oder leiser gemacht werden können.

Ein bestimmter Zustand wäre z. B., dass der Bewegungssensor eine Bewegung erkennt, womit der Alarm aktiviert wird („data“ nimmt den Wert „P“ an –> Funktionsaufruf auf „befehl (data)“ –> Ausführung von Funktion „play()“.)

Abbildung 11: Befehle für MP3-Funktionen (Code)

Baumaterialien:

Elektrotechnik/ Schaltplan:

Pin-Nummer | Bauteil

Auch wenn die letzte Phase vor der Präsentation nicht einfach war, da ein von zwei Teammitgliedern aufgrund des Coronavirus für knappe zwei Wochen ausfiel, haben wir das Projekt planmäßig umgesetzt. Wir hatten auch geplant ggf. weitere Authentifizierungsmethoden oder sogar die Handschrifteingabe von Zahlen mithilfe von maschinellem Lernen umzusetzen, jedoch konnten wir diese „Nice to have“ Sachen schwer mit der ungeplanten „Zwangpause“ des einen Teammitglieds implementieren.

Eine Gruppe aus dem folgenden Semester könnte also unser Projekt fortführen. Ein Beispiel dafür wäre eine Erweiterung der Authentifizierungsmethoden mithilfe von FaceID, Fingerprint und RFID-Erkennung. RFID ist ein kontaktloser Datenaustauschstandard, mit dem man z. B. bei einem Einzelhändler kontaktlos zahlen kann. Zudem wäre es möglich dem Roboter Räder hinzuzufügen, mit denen er sich dem bewegenden Objekt nähern kann.

Als Learning in der Reflektion nehmen wir mit, dass wir im Nachhinein noch ein bisschen mehr Puffer für Dinge einplanen, die am Anfang leicht zu bewältigen wirken, jedoch danach das Gegenteil sich herausstellt. Besonders in den ersten Wochen, sollte man den schweren Teil des Projekts abarbeiten, sodass man nicht in Zeitschwierigkeiten gerät.

Wachhund: Code und Libraries