Handysteuerung für einen Süßigkeitenautomaten

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

Im Rahmen unserer open-oose-Session „the internet of sweet things“ haben wir eine Software geschrieben, um einen Süßigkeitenautomaten zu steuern.

Moment! Ihr habt was?

Also: wir haben einen Süßigkeitenautomaten -- neudeutsch: Candy-Grabber -- gekauft, gibt's (z.B.) bei Amazon für ca. 30 Euro. Der wurde erstmal aufgeschraubt, die Drähte der Steuerungshebel gekappt und an einen Raspberry Pi angeschlossen. Danach machten wir uns daran, eine node.js-App zu schreiben, welche eine Web-Seite für mobile Geräte bereitstellt. Diese Seite liest die aktuelle Orientierung des Geräts aus, wie beispielsweise nach vorne, hinten, links oder rechts gekippt und sendet Steuerbefehle an die node.js-App. Diese setzt daraufhin via I2C-Bus die Motoren des Automaten in Bewegung.

Interessant. Aber warum?

Weil's Spaß macht und weil wir's dürfen. Erwähnten wir schon mal, dass wir bei oose keine Vorgesetzten haben, die uns so etwas verbieten würden? Aber es gibt noch weitere Gründe!

Zum einen lässt sich anhand dieses Beispiels gut diskutieren was das Internet of Things denn eigentlich ist. Keine der eingesetzten Technologien oder Geräte sind besonders neu (HTTP seit 1991, I2C seit 1982, node.js seit 2009, Raspberry Pi seit 2011, Greifautomaten seit dem frühen 20. Jahrhundert) und Automaten fernzusteuern ist ebenfalls keineswegs revolutionär. Es scheint erst die Verkettung aller einzelner Elemente zu sein, welche eine neue User-Experience bietet und den Hype um IoT begründet.

Zum anderen können in diesem Beispiel, mit seiner überschaubaren Fachlichkeit, viele Aspekte der Software-Entwicklung untersucht werden. Sowohl mobile und Web-Aspekte als auch hardwarenahe Überlegungen lassen sich hier gut demonstrieren. Große Teile des Software-Entwicklungsprozesses, von der Frage „Was ist die Lösungs- oder Produktvision?“, „Welche Nutzungskontexte lassen sich ermitteln?“ über „Welche Strukturen sind hierfür geeignet?“ und „Welche Technologien können mich dabei unterstützen?“ bis zu „Wie soll die Anwendung später betrieben werden?“ und „Was wollen wir monitoren?“ können diskutiert und schnell ausprobiert werden. Daher soll dieses Beispiel u.a. in unserem Seminar „Software-Architektur für Entwickler“ als Anschauungsbeispiel dienen.

Das Projekt gab uns Trainern auch Möglichkeiten, verschiedene „Weltsichten“ und „Selbstverständlichkeiten“ in unterschiedlichen oose-Themenfeldern zu hinterfragen, sich auszutauschen und zu diskutieren: Ein „Wie geht das technisch konkret?“ vs. „Warum ist das für einen Nutzer überhaupt interessant?“

Und wenn man demnächst auf unserem Campus mit seinem Handy Süßkram angeln kann, wird sich sicherlich auch niemand beschweren.

Butter bei die Fische: wie geht das jetzt genau mit dem Handy und dem Süßkram?

Vier Schritte sind auszuführen: Einkaufen, Verkabeln, Programmieren, Naschen.

Einkaufen

• Raspberry Pi 3 (plus Zubehör: Netzteil, SD-Karte, ...)
• Candy Grabber
• Schrittmotor Hat von Adafruit
• 2-Kanal-Relais-Modul (5v)
• Smartphone mit Webbrowser (hoffentlich schon vorhanden)

Verkabeln

Mit einem kleinen Kreuzschraubenzieher lässt sich das Gehäuse öffnen und der Automat gewährt einen Blick auf sein Innenleben. Diesem rückt man mit Zange oder Taschenmesser zu Leibe: die Anschlussleitungen an der vorhandenen Platine und dem Lautsprecher werden abgetrennt (Zu allererst das Kabel zum Lautsprecher. Sie werden wissen warum das wichtig ist.) und Speaker und Platine entfernt. Die vorhandene Verdrahtung der Motoren im Süßigkeitenautomaten wird weiter genutzt, inklusive der Endkontakte welche die Motoren bremsen, wenn sie den Rand des Automaten erreicht haben. Um die Motoren zu steuern, werden sie am Motor Hat angeschlossen welcher wiederum mit den SDA1/SCL1-Pins des Raspberry Pis verbunden und damit via I2C-Bus ansprechbar wird. Für die XY-Bewegungsachsen verbindet man jeweils eine Leitung vom Motor Hat zum entsprechenden Motor des Automaten so, dass sie durch das Relais-Modul unterbrechbar ist. Nun kann man durch Schalten des jeweiligen Relais die Fahrtrichtung des Greifarms umkehren. Das Relais-Modul wird mit 5V-Spannung durch den Raspberry Pi versorgt und mittels zweier GPIOs des Raspberry Pis geschaltet (AN/AUS abhängig von der gewünschten Laufrichtung des Motors).
Fotos der Verdrahtung bzw. Schaltbild werden "demnächst" im Repository auf bitbucket, siehe unten, hinterlegt.

Die Steuerung programmieren

Wie schon erwähnt, soll die Steuerung durch eine node.js-Anwendung erfolgen, welche einen Web-Client bereitstellt, welche Steuerbefehle über http sendet, die wiederum in I2C-Nachrichten für den Motor-Hat übersetzt werden.

Mit dem express-generator lässt sich in Sekunden der Anwendungsrumpf generieren, auf dem wir unsere Steuerung aufsetzen wollen. Der Rumpf stellt eine Index-Seite bereit und routet Requests an Funktionen in den Dateien index.js et al. Die index.js wird so angepasst, dass Sie unseren Web-Client ausliefert. Dieser besteht aus einem HTML-Dokument, ergänzt durch etwas JavaScript, welches die Orientierung ausliest

und ggf. die Steuer-Befehle absendet (das geschieht in den Funktionen move(...) und stop()). Diese Befehle richten sich an ein HTTP-Interface (implementiert in der node.js-App) welches PUT-Requests an die URIs

• /move/right
• /move/left
• /move/down
• /move/up
• /move/not
• /grab

entgegennimmt und die, für die jeweilige Aktion notwendigen, I2C-Nachrichten an den Motor-Hat sendet.

An weiteren Details Interessierte können sich den vollständigen Quellcode hier ansehen, seien aber gewarnt, dass dies noch ein Bastelprojekt und keine Demo für Clean Code ist. Software-Craftsmen mögen uns verzeihen (oder wenigstens nicht verachten).

Naschen

:-)

Seid ihr jetzt fertig oder gibt's noch weitere ToDos & Ideen für den Automaten?

Dutzende:

• Die Anwendung sollte noch robuster werden, um auch auf Messeständen für Freude zu sorgen.
• Über eine Lichtschranke am Auswurf müsste man noch prüfen, ob auch etwas Süßes rauskam.
• Jene Kolleginnen, welche unseren Blutzuckerspiegel verwalten (unser Veranstaltungsmanagement), sollten Mails erhalten, wenn der Automat wieder befüllt werden muss.
• Falls doch mal was schief geht, soll eine einfache Admin-Oberfläche es ermöglichen, den Automaten in korrekte Zustände zu versetzen.
• Das Monitoring ist noch nicht fertig.
• Lohnt sich eigentlich Continuous Delivery für solch ein banales Stück Software?
• ... und Continuous Deployment?
• Nicht, dass wir darauf stolz wären, aber es fehlen noch Tests. Wie geht das eigentlich mit I2C?
• Alexa hockt gelangweilt auf unserem Campus. Ihr könnte man doch beibringen, den Automaten auf Zuruf zu bedienen.
• ...

Danke für die Auskünfte. Was mache ich jetzt mit dem Wissen?

Ihre Handlungsoptionen, in aufsteigender Extrovertiertheit:

• Wissend nicken, dann weiter surfen. Waren Sie schon auf heise.de?
• Dieses Projekt zu Hause nachbauen (einkaufen, verkabeln, programmieren, naschen)
• Dies ist ein Blog mit Kommentarfunktion. Sie könnten uns mit Lob für unsere tollen Ideen überschütten. Oder -- in guter Internet-Tradition -- uns erklären, warum das alles Blödsinn ist und was wir alles falsch gemacht haben.
• Diesen Link teilen (z.B. auf Twitter oder Facebook)
• Zu uns kommen und den Candy-Grabber ausprobieren!