Der erste Entwurf
Die erste Projektidee war ein System, mit dem sich Räume buchen lassen. Für den Raum selbst gibt es ein Gerät, über das man sich per NFC-Chip einchecken kann.
Die Personen die sich im Raum anmelden, sollen mit Hilfe von Node-RED in einer Anwesenheitsliste für den jeweiligen Raum eingetragen werden. Wenn die vorgegebenen Kapazitäten für den jeweiligen Raum erreicht sind, sollen keine Anmeldungen mehr möglich sein und der Raum darf nicht betreten werden.
Ein solches System soll den Alltag an Universitäten, Schulen und Betrieben vereinfachen. Gegebenenfalls könnte man darüber auch eine Kontaktverfolgung aufbauen und Corona-Infektionsketten leichter nachverfolgen.
Folgendes Diagramm dient zur Veranschaulichung der jewiligen Konzepte:
Skizze zum Konzept des Scanners:
Aufgabenverteilung
Die vorläufig Aufgabenverteilung sieht folgendermaßen aus:
Das Programmieren vom Backend und der dazugehörigen Webseite übernimmt Hannes.
Tom ist für die Modellierung und das Design für das Gehäuse des Mikrocontrollers und des Scanners zuständig.
Für den Zusammenbau und das Programmieren des Mikrocontrollers und die dazugehörigen Bauteile sind Tom, Christian und Lasse verantwortlich.
Die Projekt-Dokumentation übernehmen Christian und Lasse.
Zusammenbau – Scanner
Im folgenden Diagramm sind die konkreten Schnittstellen für den Scanner zu sehen. Anhand dieser hat sich die Zusammenstellung der Hardware orientiert.
Folgende Komponenten werden für den Scanner benötigt: ESP-8266, OLED-Display, RFID-Scanner, Battery-Shield, Triple Base.
Der Mikrocontroller ESP-8266 dient zur Steuerung des OLED-Shields und des RFID-Shields.
Das OLED-Display soll ein visuelles Feedback geben, welches darauf basiert, ob ein Raum voll ist oder nicht. Dies kann ein kurzer Text sein oder ein Symbol wie ein Häkchen oder ein Kreuz.
Der RFID- Scanner ist die eigentliche Scan-Schnittstelle, die erkennt, ob ein NFC-Chip angelegt wurde.
Der Battery-Shield soll als Stromversorgung für den Mikrocontroller dienen und die Möglichkeit bieten ohne Stromkabel zu funktionieren.
Die Triple Base dient als Verbindungsplatine auf die die Komponenten gesteckt und gelötet werden. Somit werden unnötige Kabelverbindungen vermieden.
Die Anordnung der Hardware-Elemente sieht folgendermaßen aus:
Um Platz zu sparen, wurde beim Triple Base Shield ein Element abgetrennt und der Battery-Shield unterhalb des Triple Shields angebracht.
Hier hat sich später allerdings herausgestellt, dass beim Entfernen des Elements der Stromkreis der Triple Base beschädigt wurde. Beim testen eines vorläufigen Codes sind nicht nachvollziehbare Fehler aufgetreten. Da keine genaue Ursache erkennbar war, musste alles nochmal von vorne Zusammengebaut und gelötet werden, wobei leider auch neue Bauteile verwendet werden mussten.
Beim genaueren Stromkreis testen wurde festgestellt, dass auf einer Seite des Triple Shields die Ground-Verbindung nicht durchgeleitet wurde. Dies lies sich leicht mit einer zusätzlichen Kabelverbindung zur funktionierenden Seite lösen.
3D-Modellierung und Anfertigung
Vor einem konkreten Designentwurf wurde ein kleiner Deckel modelliert und ausgedruckt (siehe folgende Abbildung). Dieser sollte ein OLED-Display und zwei LEDs als visuelles Feedback beinhalten. Diese Idee wurde später verworfen, da man zum Entschluss kam, dass auch nur ein OLED-Display ausreichen würde und LEDs nicht nötig sein.
Nachdem ein kleiner Kasten modelliert und gedruckt wurde, der nur das OLED-Display und dem Mikrocontroller enthalten sollte, ließ sich erkennen, dass dieser Kasten nicht groß genug war. Der Kasten wurde vergrößert, so dass zusätzlich noch der RFID-Scanner, ein Akku und das zugehörige Batterie-Shield hineinpassten.
Für die Modellierung wurde ein 3D-Modell der Bauteile auf dem Protoboard erstellt, um die Maße besser einschätzen zu können und Öffnungen im Deckel und der Kiste genau zu Platzieren. Ausserdem wurde eine Halterung für das komplette Board mit den Bauteilen in der Kiste platziert. Folgende Bilder dienen zur Veranschaulichung der 3D-Modellierung:
Es waren mehrere Durchläufe der Modellierung mit Entwurf und Druck nötig, um die Kiste an die Technik anzupassen. Es wurde immer wieder ein Entwurf gedruckt, getestet und dann angepasst.
Für den Raspberry-Pi wurde ein vorgefertigtes Modell benutzt. Das Modell wurde mit einer Verzierung auf dem Deckel und Hexagons auf der Bodenplatte angepasst (alles im Rahmen der Lizenz).
Quelle: https://www.thingiverse.com/thing:3361218
Lizenz: https://creativecommons.org/licenses/by/4.0/
Ein in TinkerCad vorgefertigtes 3D-Modell (siehe folgende Abbildung) des Raspberry-Pi war hier sehr hilfreich. Diese konnte man in das Modell setzen und prüfen, ob noch alles so passt wie es sollte.
Dieses Modell wurde schließlich im 3D-Drucker angefertigt:
Backend Programmierung
Es wurde die Entscheidung getroffen das Backend in Python zu programmieren, da Python deutlich flexibler ist als Node-RED. Die Python-Skripte sollen dabei auf einem Raspberry Pi ausgeführt werden.
Datenbank
Als Datenbanksystem kommt in diesem System MongoDB zum Einsatz. Eine NoSQL Datenbank, die mit JSON-ähnlichen Dokumenten arbeitet.
Für MongoDB wurde sich entschieden, da eine NoSQL Datenbank etwas flexibler in Bezug auf die Strukturierung ist, verglichen mit relationale Datenbanken.
Zur Veranschaulichung der Datenbankstruktur wurde folgendes ERD (Entity-Relationship-Diagramm)erstellt
MQTT
Für die Integration mit MQTT wurde die paho-mqtt Python Libarary verwendet. Dabei wurde das Design der Schnittstelle so ausgelegt, dass lediglich ein Topic verwendet werden muss (” cardreader/+/scan”) – sowohl für das ein- als auch das auschecken. Die einzelne Entscheidung, welche von beiden Aktionen ausgeführt werden soll, trifft das Backend selbständig.
Der Platzhalter wird dabei mit einer eindeutigen ID des Scanners ersetzt. Die Daten des gescannten Chips werden dabei als Nachricht übertragen
Interface
Zu Anfang war ein einfaches CLI-Interface geplant, mit dem Infektionen eingetragen werden konnten, welches auch erstellt wurde. Da danach aber noch viel Zeit übrig war und das Interface nicht vollkommen zufriedenstellte, wurde das Interface auf eine Website umgestellt.
Hierbei kam zum einen als Backend Flask (Python) zum Einsatz. Es wurde sich dafür entschieden, da der MQTT-Service bereits mit Python programmiert wurde und somit keine weitere neue Technologie eingebunden werden musste.
Zum anderen wurde für das Frontend Nuxt.js verwendet. Für Nuxt wurde sich entschieden, da Nuxt einfacher aufzusetzen ist als “Plain-Vue.js” und zudem einige Teammitglieder bereits Erfahrung mit Vue hatten.
Die api deS interface
| Pfad | Methode | Parameter/Body | Rückgabewert | Kommentar |
| /api/students/ | POST | Userdaten als JSON mit folgenden Elementen: name : String – Der Name des Studierenden email: String – Die Email des Studierenden card_hash : String – Der Hash der Daten der Campuscard | Die neue ID des angelegten Studierenden | |
| /api/students/ | GET | keine | Ein Array mit allen Usern | |
| /api/students/<mail>/contacts/ | GET | <mail> – Die Email des Users | Ein Array mit allen Userids, die betroffen sind von dieser Meldung | |
| /api/students/<mail>/confirm-report/ | POST | <mail> – Die Email des Users | Keiner | Sendet die Emails |
| /api/students/ | DELETE | ?id – Die Id des Users, der gelöscht werden soll | Keiner | |
| /api/scanners/ | GET | room_id – Die Id des Raumes | Ein Array mit allen Scannern, die dem Raum zugeordnet sind | |
| /api/scanners/ | POST | Scannerdaten als JSON mit folgenden Elementen: name : String – Der Name des Scanners room : String – Die Id des Raumes, dem der Scannner zugeordnet werden soll | Keiner | |
| /api/scanner/ | DELETE | ?id – Die ID des Scanners, der gelöscht werden soll | ||
| /api/rooms/ | GET | Keine | Ein Array aller Räume | |
| /api/rooms/ | POST | Daten des Raumes als JSON mit folgenden Elementen: roomName : String – Der Name des Raumes roomNumber : String – Die Nummer des Raumes buildingName : String – Der Name des Gebäudes, wo sich der Scanner befindet. | ||
| /api/rooms/ | DELETE | ?id – Die Id des Raumes, der gelöscht werden soll. |
Ermittlung der Kontakte
In der Datenbank werden die Zeiträume des Check-ins bzw. Check-out als Unix-Timestamp in zwei Datenbankfeldern gespeichert. Zur Ermittlung, welche Studierende möglicherweise Kontakt zur infizierten Person hatten, also zur selben Zeit im selben Raum eingecheckt waren, gibt es drei Fälle zu unterscheiden, wo sich Zeitabschnitte überschneiden:
Seinen: A, B zwei Studierende und A ist mit Covid-19 infiziert.
- Fall 1: B checkt sich nach A ein, aber checkt auch wieder vor A aus.
- Fall 2: B checkt sich nach A ein (aber bevor A sich wieder auscheckt) und B checkt sich nach A wieder aus.
- Fall 3: B checkt sich vor A ein aber checkt sich nachdem A sich eincheckt hat wieder aus.
Alle diese Fälle wurden im Code abgedeckt.
Das fertige Projekt
Der Scanner funktioniert mit Batterie und kann per Mikro-USB-Kabel geladen werden. Das Backend, welches auf dem Raspberry Pi läuft, benötigt eine Permanente Stromverbindung.
Folgendes Video demonstriert die Funktion des Scanners:
Fazit, Lessons Learned und mögliche Verbesserungen
Für diese Projekt wurde ein Scanner erstellt. Hierfür wurden Mikrocontroller, OLED, RFID, Battery-Shield und TrippleBase verlötet und ein entsprechendes Programm geschrieben. Zusätzlich wurde ein Raspberry-Pi programmiert, der eine Webseite hostet und als Datenbank für den Scanner agiert. Als Gesamtsystem soll es hiermit möglich sein eine Raumnutzungs Übersicht zu nutzen, über welches sich Personen per Chip oder Karte einchecken können.
Erreichte Ziele:
Ziel war das rechtzeitige Fertgstellen der einzelnen Aufgaben und die erfolgreiche Umsetzung des geplanten Konzepts. Dabei wurden zwei Meilensteine erreicht. Einer davon war das Konzept für den Scanner umzusetzen. Das bedeutet also ein funktionsfähiger Prototyp in einer modellierten Box mit fertigen Code. Der zweite Meilenstein war auf das Backend fokussiert. Hier war das Ziel eine handliche Website zu designen und den Raspberry Pi als Server mit einzubeziehen. Diese beiden Meilensteine wurden mit Erfolg erreicht.
Lessons Learned:
Jedes Gruppenmitglied hat ein unterschiedliches Aufgabenfeld abdecken können, um so gemeinsam die eigentliche Aufgabe zu lösen. Es gab regelmäßige Kommunikation über Fortschritt und erreichte Ergebnisse. Dies ist eine effektive Methode zum arbeiten, da sich so jeder auf seine Stärken fokussieren kann und mehrere verschiedene Bereiche gleichzeitig abgedeckt werden können. So verläuft das Arbeiten am Projekt deutlich optimaler, als wenn sich die Gruppe für jeweils eine Aufgabe zusammensetzt.
Zwar gab es immer wieder Probleme bei der Umsetzung für den Raspberry Pi, allerdings hat man sich davon nicht unterkriegen lassen und es dann mit einer anderen möglichen Lösung probiert. Hier hieß es immer einen kühlen Kopf zu bewahren und Geduld mitzubringen.
Verbesserungsvorschläge:
Das Design des Scanner-Gehäuses ist etwas eintönig. Hier könnte ein innovatives Design für ein mehr anschauliches Aussehen sorgen. Zum Beispiel könnte die Scan-Fläche über dem RFID-Scanner mit transparentem Material erstzt weden. So würde das “Wellensymbol” des Bauteils sichbar sein.
Ein akkustisches Signal zum Scannen wäre auch eine gute Ergänzung und ließe sich relative leicht umsetzten. Man könnte zum Beispiel drei verschiede Tonfolgen für Ein- und Aus-Checken und die Fehlermeldung implementieren.
Quellen
- https://www.emqx.com/en/blog/how-to-use-mqtt-in-python. [Abgerufen am 23.8.2021]
- https://www.thingiverse.com/thing:3361218. [Abgerufen am 15.9.2021]