Foodbonaut

Aus HRW FabLab MediaWiki
Wechseln zu: Navigation, Suche

Foodbonaut

Foodbonaut.jpg


Entwickler

Joshua Burggraef, Ahmad Karim Dahrouj, Thomas Flinkow

Programmiersprache

C++ (ESP), Java (Server)

Hardware

ESP-32 Devkit C, RFID-RC522

Der Foodbonaut ist ein Gerät, das die Vergabe der Essensmarken in den Rheinbabenwerkstätten der Diakonie Bottrop automatisieren soll.

Hintergrund[Bearbeiten]

In den Rheinbabenwerkstätten arbeiten Beschäftigte in verschieden großen Gruppen. Beim Mittagessen gibt es im Grunde immer eine vegetarische und eine fleischhaltige Option. Jeder Beschäftigte einer Gruppe bekommt einen im Folgenden "Essensmarke" genannten Plastikchip in der Farbe grün (für die vegetarische Option) oder rot. Die Küchenleitung legt in mehr oder weniger regelmäßigen Abständen in der verwendeten Software (Vivendi) fest, welche Gruppe an welchem Tag wie viele grüne und wie viele rote Essensmarken bekommt.

Jeden Morgen wird anhand einer ausgedruckten Liste von Hand für jede Gruppe die richtige Anzahl an roten und grünen Essensmarken in die Schalen gefüllt, die dann vom Gruppenleiter mit zu ihrer Gruppe genommen werden.

Dieser Prozess kostet jeden Morgen Zeit, ist fehleranfällig (verzählen) und nicht flexibel, wenn sich Beschäftigte morgens krankmelden.

Funktionsweise[Bearbeiten]

Unser Foodbonaut greift genau da an: die Küchenleitung speichert die Verteilung einfach als Excel-Datei auf ihrem Rechner. Wenn sich Beschäftigte krankmelden, korrigiert sie einfach die Verteilung und speichert die Datei erneut. Der ganze zeitintensive Prozess wird also reduziert auf das Erstellen bzw. Bearbeiten und Speichern der Verteilung in Vivendi.

Entwicklung[Bearbeiten]

Hardware[Bearbeiten]

Da der Foodbonaut über das Internet mit einem Server kommunizieren sollte, bietet sich ein Mikrocontroller an, der von Haus aus WLAN-Unterstützung bietet. Wir haben uns daher für einen ESP-32 entschieden.

Komponente Kosten
ESP-32 Dev Kit C 8 €
USB zu Micro-USB (Datenkabel) 5 €
2x 5V Servos, je 5 €
RFID-RC522 3 €
PCB-Lochplatinen ~4 €
Breadboards, Kabel, LEDs, etc. ~10 €
Gesamtkosten ~35 €
Schaltplan













Programmierung[Bearbeiten]

Mikrocontroller (ESP)[Bearbeiten]

Der grundsätzliche Programmablauf ist relativ simpel: es wird solange gewartet, bis eine neue Schale auf das Gerät gestellt wird. Dann wird der RFID-Tag ausgelesen und an den Server gesendet. Dieser ermittelt aus dem RFID-Tag die Gruppe und gibt die Verteilung der Essensmarken für diese Gruppe am heutigen Tag zurück (mehr zur Serverseitigen Programmierung unten).

void loop()
{
    // Prüfen, ob eine neue Schale erkannt wurde und falls ja, RFID-Tag scannen.
    if (read_rfid())
    {      
        int green_count = 0;
        int red_count = 0;

        // RFID-Tag an der Server senden und die Anzahl der roten und grünen Marken erhalten.
        if(!get_red_green_count(&red_count, &green_count))
        {
            // Fehler bei der WLAN Verbindung -> WLAN-Fehlerleuchte blinken lassen.
            blink_led(LED_WIFI);
            return;
        }

        // Die vom Server erhaltene Verteilung der Essensmarken in die Schale werfen.
        emit_coins_green(green_count);
        emit_coins_red(red_count);

        // Alle Marken wurden ausgeworfen -> Fertig-Leuchte blinken lassen.
        blink_led(LED_RDY);
        delay(10);
    }
}

Server[Bearbeiten]

Der Server stellt eine Informationsquelle für das System dar.

Dateiformate[Bearbeiten]

Beim Starten des Programms werden zwei Excel-Dateien eingelesen. Zum einen die Excel-Datei, welche die Verteilung der Essensmarken für alle Gruppen für einen großen Zeitraum enthält, sowie eine Datei, die zu jeder Gruppe die tatsächliche RFID NUID (d.h. die Zuordnung der Schalen zu den Gruppen) enthält.

Die aus Vivendi exportierte Excel-Datei sieht wie folgt aus:

4002 Gruppe 5 Montag Dienstag Mittwoch Donnerstag Freitag Samstag Sonntag Wochensumme

grünes Menü        1        2        2          -       -       -       -           5

rotes Menü         1        1        2          1       -       -       -           5

 

4004 BBB RBW Montag Dienstag Mittwoch Donnerstag Freitag Samstag Sonntag Wochensumme

grünes Menü       3        2        4          4       2       -       -          15

rotes Menü        1        2        0          1       3       -       -           7

...

und die Datei, die RFID NUIDs zu den tatsächlichen Gruppen zuordnet, speichert die Namen der Gruppen und die zugeordnete RFID NUID im Format Name:NUID und sieht so aus:

4002 Hauswirtschaft 2:D3159803
4002 Verpackung 2:175D303B
4019 Kunstatelier Freihand:D3667F03
...

Wird dann irgendwann eine Anfrage mit gültiger bzw. dem Server bekannter RFID NUID empfangen, antwortet der Server mit der Anzahl von grünen und roter Essensmarken für diese Gruppe für den heutigen Tag. Im Fehlerfall wird ein Fehlercode zurückgesendet, der dem Benutzer dann durch Blinken einer LED signalisiert, dass etwas schief gelaufen ist.

Ausschnitt aus dem Code, der angekommene Anfragen empfängt:

 public void readRequest() throws IOException 
 {
     BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(socket.getInputStream()));
     char[] buffer = new char[200];
     
     // Lesen der empfangenen Nachricht und Speichern der RFID NUID.
     int countOfRecivedMessage = bufferedReader.read(buffer, 0, 200);
     rfidCode = new String(buffer, 0, countOfRecivedMessage);  
   
     System.out.println(rfidCode); // empfangene RFID NUID in der Console ausgeben
 }

Ausschnitt aus dem Code, der auf angekommene Anfragen antwortet:

private void createResponse() throws IOException 
{
    PrintWriter printWriter = new PrintWriter(new OutputStreamWriter(socket.getOutputStream()));

    // Anhand der empfangenen RFID NUID wird die Anzahl an roten und grünen Essensmarken ermittelt.
    String response = GroupService.getGroupDataByRFID(rfidCode);

    printWriter.print(response); // Antwort wird an den Foodbonaut gesendet 
    printWriter.flush();
}

Schwierigkeiten[Bearbeiten]

Ein kleines Problem war, dass der RFID-Scanner, der über SPI mit dem ESP-32 kommuniziert, bei gesteckten Verbindungen nicht richtig funktionierte. Daher musste schon recht früh gelötet werden.

Ausblick[Bearbeiten]

Als nächste Schritte vorstellbar wären ein äußeres, abnehmbares Gehäuse bzw. eine Verkleidung, um das Gerät für die Verwendung in Großküchen robuster und ansehnlicher zu machen. Weiterhin sollte versucht werden, die Robustheit und Zuverlässigkeit des Auswurfsystems zu steigern, um im laufenden Betrieb reibungslos zu funktionieren.