Fazit

Das Projekt ist von der Ideenfindung bis zum fertigen Endprodukt beinahe reibungslos verlaufen – Kommunikation und Zusammenarbeit funktionierten sehr gut und eventuelle Meinungsverschiedenheiten wurden konstruktiv aufgearbeitet.

In der Organisation hat die eingangs erstellte GoogleDocs Tabelle sehr dabei geholfen, den Überblick zu bewahren und Treffen zu organisieren – die wichtigsten Meetings waren jedoch meist die, welche spontan berufen wurden, um Lösungen für akute Probleme zu finden.

Während der Softwareentwicklung gab es ein paar wenige Hürden zu überwinden, mit ein wenig Zeit gelang dies jedoch mehr oder weniger elegant.

Beim Druck der 3D-Modelle gab es unvorhersehbare Komplikation, weshalb zeitlich leider keine zweite Iteration mehr möglich war, welche noch ein paar kleinere Fehler behoben hätte.

Lessons Learned

  • Unvorhersehbare Komplikationen: Beim 3D-Druck kam es zu einem Problem außerhalb unserer Macht, was dazu führte, dass wir im keine Zeit für einen eventuellen zweiten Design- und Druckdurchgang mehr hatten – für die Zukunft werden wir für solche Eventualitäten mehr Pufferzeit einplanen.
  • Meetings: Um bei Meetings bei kommenden Projekten nicht verspätet teilzunehmen und von den Projektmitgliedern erinnert werden zu müssen, auch am PC die Erinnerungsfunktion des Kalenders nutzen.
  • Spontanität: Während eine gute Planung für uns den Projektablauf sehr erleichtert hat ist es doch wichtig zu erwähnen, dass die für uns wichtigsten Meetings meist die waren, welche spontan als Reaktion auf ein akutes Problem stattgefunden haben. Natürlich ist es besser, wenn diese nicht stattfinden müssen – aber wenn sie es tun, ist es sehr gut, gute Entscheidungen auch auf der Stelle treffen zu können.

Verbesserungen für v2

Der begrenzten Projektzeit geschuldet gibt es einige Punkte am Projekt, welche noch verbesserungswürdig sind – entweder, weil sie noch gar nicht berücksichtigt wurden, oder weil sie aus verschiedenen Gründen noch nicht perfekt umgesetzt werden konnten.

Software:

  • Zugriffsrechte: Aktuell sind sowohl die NodeRED-Instanz als auch der MQTT-Broker frei für jeden im gleichen Netzwerk zugänglich. Beide bieten jedoch die Möglichkeiten, eine Authentifizierung zumindest per Benutzername und Passwort zu verwenden.
    Hinzu kommt, dass auch die Messenger-Dienste noch keinerlei Filter haben, der nur bestimmten Benutzern erlauben würde, Befehle für das System zu Senden. Die verwendete Telegram-API-Zugriffs-Implementierung bietet hierfür schon eine Möglichkeit an, diese ist jedoch nicht dynamisch änderbar – eine eigene, für beide Messenger wieder verwendbare Lösung wäre also vorzuziehen.
  • Support für mehr Messenger: Aktuell werden von MED Telegram und Discord unterstützt, da beide vergleichsweise einfache Möglichkeiten für automatisierte Interaktionen bieten. Generell sind diese jedoch nicht die weitverbreitetsten Messenger-Dienste – Unterstützung für weitere Dienste wäre also wünschenswert.
  • Code-Verbesserungen: Im Quellcode für die Microcontroller gibt es zwei – kommentierte – Ungereimtheiten, für welche wir bis dato jeweils einen etwas unschönen Workaround benutzen müssen. Diese sollten nach Möglichkeit behoben werden.

Design:

  • GPIO-Cap für das RasPI-Case: Ursprünglich wurde eine Abdeckung für GPIO Pins modelliert, die noch angepasst werden muss, bezüglich der belegten Pins.
  • Display/Case Anpassungen: Wir haben im Case eine Halterung für das Display eingebaut, dabei allerdings keine Einkerbung für die herausstehenden Pins eingeplant. Dadurch sitzt das Display nicht vollkommen eben und ist auch nicht bündig am rand des Cases, sondern leicht schieß und etwas weiter drinnen. 
  • MC Halterung im Case: Damit der MC im Case nicht wackelt haben wir eine Halterung für ihn mit eingebaut. Dabei haben wir übersehen, dass er von einem Kabel etwas nach hinten geschoben wird. Dadurch wurde der MC versetzt angebracht, sodass er weiter hinten sitzt. Dafür sind die letzten beiden Pins nicht angeschlossen. 
  • Kabelverlauf: Die Kabel laufen ohne eine höhere Ordnung durch den Case es wäre schöner (ästhetischer) gewesen wenn wir eine Halterung für den Kabelverlauf eingebaut hätten. 
  • Höhe und Breite des Mirco-USB Anschlusses: Für leichteres Aufladen mit jedem Micro-USB Kabel hätte das Anschlussloch etwas größer sein sollen. Dadurch das der MC weiter als geplant im Case sitzt macht es den Anschluss noch schwieriger zu erreichen. 

Hardware:

  • Reed-Switches mit längeren Kabeln: Aktuell verwendet der Haustür-Detektor Reed-Switches mit relativ kurzen Kabeln, welche eine Anbringung leicht erschweren können. Ein Modell mit längeren Kabeln wäre hier sinnvoll.
  • Größeres LCD: Das aktuell verwendete LCD bietet Platz für 32 Zeichen. Es gibt jedoch auch gleichgroße Modelle, welche bis zu 80 Zeichen unterstützen.

3D-Modellierung

Verwendete Werkzeuge

Modellierungssoftware: Fusion360

Messwerkzeug: digitaler Messchieber

Raspberry-PI-Gehäuse

Das Modell besteht aus dem Gehäuse selbst, sowie dem Deckel

Bemaßung: Deckel (LxBxH):  63.6×24.8×2.7mm, Gehäuse (LxBxH): 88.9×62.3×24.5mm

Deckel
Gehäuse

Modellierungsprozess

Um den Zeitaufwand zu verringern, wurde vor der Modellierung nach bereits bestehenden Gehäusen für Raspberry-PIs gesucht. Dabei wurde sich dann für dieses Gehäuse entschieden. Bei der Anpassung wurde das bestehende Modell auf 103,5% skaliert, da es eng ausfallen solle. Zudem wurde eine Wandhalterung hinzugefügt und ein Deckel für die Aussparung der GPIO Pins modelliert. Letzterer wurde nicht gedruckt, da es zu Komplikationen kam. Außerdem trägt der Deckel nichts zur Funktion bei und auch nicht zur Optik, wenn der Raspberry-PI an der Wand hängt.

Um sicher zu gehen, dass das Modell nicht zu groß und nicht zu klein ist, wurde der Raspberry-PI nach der ersten Vergrößerung ausgemessen. Daraus ergab sich eine Verkleinerung.

Klingelkasten und Briefdetektor

Wie der Klingelkasten besteht der Briefdetektor aus dem Gehäuse selbst und dem Deckel.

Bemaßungen: Klingelkasten (LxBxH): 108x73x25mm, Klingeldeckel (LxBxH): 104x72x2mm, Briefdetektorkasten (LxBxH): 63x38x24.5mm, Briefdetektordeckel (LxBxH): 59x37x2mm

Klingelkasten (innen)
Klingekkasten (außen)
Klingeldeckel
Briefdetektorkasten und -deckel

Modellierungsprozess

Für die Behausungen der Klingel mit Display und dem Briefdetektor wurde zunächst ermittelt, wie man die elektronischen Bauteile anordnet. Dabei wurde einerseits auf ein möglich kompaktes Design gesetzt. Gleichzeitig wurde darauf geachtet, dass beim Druck so wenige Stützstrukturen wie möglich gebraucht werden, um die Nachbearbeitung der Modelle zu minimieren. Das Anordnen der Bauteile diente auch dazu die Grundmaße der Gehäuse zu erhalten. Um möglichst wenige Iteration von Prototypen zu benötigen, wurden die Maße der 3D-Modelle mit den Maßen der Anordnungen der Bauteile, sowie der Bauteile selbst, mehrmals verglichen.

Projektplanung, Aufgabenteilung und Risikomanagement

Projektplanung

Zu Beginn der Projektphase wurde innerhalb der Gruppe über eine Woche ein Brainwriting durchgeführt, in welchem zunächst grobe Ideen gesammelt wurden. Anschließend wurden diese Ideen zusammengesetzt und abgewandelt, um so die finale Projektidee zu erhalten.

Die eigentliche Bearbeitungsphase begann ab dem 31.07.2021. Ab diesem Zeitpunkt waren alle Deadlines (vgl. Tabelle) des Projekts sowie einige Meilensteine (Fertigstellung 3D-Modelle, Fertigstellung bestimmter Softwareteile, …) über eine Google Docs Tabelle festgehalten, in welche außerdem von jedem Teammitglied eingetragen wurde, an welchem Tag welche Tätigkeiten durchgeführt werden sollten.

DatumPerson(en)Tätigkeit
04.08.Jamal Frerichs, Jonas KöhlerMakerspace: brauchbare Hardware
06.08.Hagen EickhoffPlanung: Anforderungen (Soll/Muss/Kann)
26.08.Marcel OppermannMakerspace: 3D-Modelle (v1) fertigstellen und drucken
14.09.Hagen Eickhoff, Jonas KöhlerSoftware Feature-Complete
16.09AlleFertigstellung Werkstück, Dokumentation, Präsentation
Tabelle: Deadlines

Verantwortungen, Aufgabenteilung

Anhand der zuvor abgestimmten Interessensgebiete der einzelnen Gruppenmitglieder übernahm jedes einen Verantwortungsbereich innerhalb des Projekts.

Aufgaben wurden dabei primär aus dem jeweils eigenen Bereich bearbeitet, einige wurden jedoch auch gemeinsam und/oder über Verantwortungsbereiche hinaus bearbeitet (vgl. Tabelle).

PersonZuständigkeitSonstige Tätigkeiten
Hagen EickhoffSoftwareentwicklung Dokumentation, Organisation
Jamal FrerichsAufbau3D-Design, Hardwareentwicklung, Dokumentation
Jonas KöhlerHardwareentwicklungSoftwareentwicklung, Dokumentation
Marcel Oppermann3D-DesignDokumentation
Tabelle: Zuständigkeiten und sonstige Tätigkeiten

Risikomanagement

Im Vorfeld der Bearbeitungsphase wurden einige Risiken identifiziert und, sofern möglich, schützende Maßnahmen bzw. Reaktionen festgelegt.

Risiko: Ausfall einzelner Gruppenmitglieder (z.B. krankheitsbedingt)
mögliche Auswirkungen: je nach Phase; leichter bis schwerer Projektverzug
Vorbeugung: Jeden Tag: aktuelle, digitale Arbeitsfortschritte im GitHub Repository sichern
Behandlung: Anderes Gruppenmitglied übernimmt temporär Aufgaben mit den Daten aus dem GitHub Repository

Risiko: Fehler bei 3D-Modellierung
mögliche Auswirkungen: keine (fertigen) Cases
Vorbeugung: Möglichst frühzeitiges Abschließen des 3D-Designs und -Drucks, um notfalls korrigieren zu können
Behandlung: sofern zeitlich möglich: Korrekturen

Risiko: Fehler bei Hardware-Zusammenbau
mögliche Auswirkungen: kaputte Hardware
Vorbeugung: Ersatzteile vorrätig haben
Behandlung: erneuter, korrigierter Aufbau

Risiko: Datenverlust
mögliche Auswirkungen: je nach Daten; leichter Verzug bis Projektverlust
Vorbeugung: Daten online speichern; je nach Art im GitHub Repository oder Google Drive
Behandlung:

Risiko: IR-Sensor nicht verwendbar (fehlerhafte Hardware, Probleme bei Software-Implementierung da Sensor unbekannt)
mögliche Auswirkungen: Projektteil nicht realisierbar
Vorbeugung: Frühzeitiger Beginn mit Implementierung und Funktionsprüfung
Behandlung: Ersetze IR-Sensor durch Reed-Switch

Anforderungen

Projektanforderungskatalog

Durch ein Brainwriting wurden alle Anforderungen an das Projekt gesammelt und aufgelistet. Anschließend wurden die Punkte in einem Meeting nach Bereich und Wichtigkeit eingeteilt und schließlich in der Tabelle 1 zusammengefasst.

Da die Hardware für das Projekt unerlässlich war gab es hier lediglich Muss- und Soll-Ziele. Diese wurden, wie in der Hardware-Dokumentation aufgezeigt, vollständig umgesetzt und stellten auch früh im Projekt ein großes Augenmerk dar.

Die Muss-Anforderungen der Software stellten die Grundlagen des Projekts dar, ohne die die eigentlichen Funktionen der einzelnen Komponenten nicht funktioniert hätten. In den Soll-Zielen wurden weitere Anforderungen an das Projekt gestellt, ohne die es zwar funktioniert hätte, jedoch nicht die Funktionalitäten umfasst hätte für die es entwickelt wurde. In den Kann-Zielen kamen schließlich noch Quality-of-Life-Funktionen hinzu, durch die MED insgesamt hochwertiger und praktikabler werden würde. Da die Softwareentwicklung insgesamt gut verlief konnten hier alle Muss-, und Soll-Ziele erfüllt werden, bei den Kann-Zielen ergab sich jedoch nur noch Zeit für die Discord-Integration, nicht aber für das Auslesen und Anzeigen des Akkustands.

Für die CAD-Entwicklung wurden lediglich wenige Anforderungen erhoben, da MED einerseits ein funktionales statt ästhetisches Produkt darstellt und andererseits die begrenzt verfügbare Zeit im Makerspace nur begrenzte Gehäuse-Prototypen erlaubt. Aus diesem Grund waren schlichte aber gut passende Cases für die Sichtbaren Module, also die Klingel und den Tür-Sensor ein Muss-Ziel. Da jedoch keine Hardware frei liegen soll war auch für den im Briefkasten nicht sichtbaren Mikrocontroller 2 ein Case geplant, weshalb es sich in den Soll-Anforderungen wiederfindet. Durch einige Komplikationen im Makerspace sowie einen späten Druckauftrag konnte schließlich das Kann-Ziel einer GPIO-Abdeckung nicht mehr erfüllt werden, was jedoch die Funktionalität von MED nicht weiter beeinträchtigt.

Motivation

Man stelle sich vor…

  • … jemand klingelt, aber man bekommt es nicht mit, denn man sitzt grade im Garten, hat Kopfhörer auf oder die Klingel ist schlicht zu leise.
  • … jemand klingelt, aber es ist niemand zu Hause – man möchte der Person aber trotzdem etwas mitteilen.
  • … man wartet auf einen wichtigen Brief, hat aber nicht die Zeit, den ganzen Vormittag aus dem Fenster zu schauen und auf die Post zu warten.
  • … man fährt in den Urlaub, möchte aber trotzdem wissen, wann jemand anderes bei einem zu Hause ist – sei es um die Blumen zu gießen oder unbefugt.

All diese Probleme werden durch MED behoben:
Das System, bestehend aus drei Geräten, bietet eine eigene Klingel, einen Bildschirm für Nachrichten, einen Magnet-Schalter für die Haustür und einen IR-Sensor, der bemerkt, wenn etwas in den Briefkasten geworfen wird.
Die so gesammelten Informationen kommen an zentraler Stelle zusammen und können von dort aus auf verschiedene, beliebig an- und abwählbare, dem Benutzer angezeigt werden – etwa als Nachrichten über verschiedene Messenger-Dienste oder als Audio-Signal. Außerdem können die Informationen können zur späteren Auswertung gespeichert werden.
Zusätzlich kann der Benutzer auch in die andere Richtung kommunizieren und per LCD Nachrichten an die Person auf der anderen Seite der Haustür senden.

Das System als ganzes zielt also darauf ab, den Benutzer ein wenig mehr Peace-of-Mind zu ermöglichen und ihren Alltag etwas zu erleichtern. Darüber hinaus bietet es mit seinen Funktionen auch Unterstützung für körperlich Beeinträchtigte – jemand, der etwa sein Gehör verloren hat, wird eine normale Klingel kaum wahrnehmen können – eine Notification auf dem Smartphone jedoch schon.

Die Idee für MED entstand im Anschluss an ein Brainwriting, dessen verschiedene Ideen zu einer zusammen verwoben wurden.