Anleitung zur Steuerung eines Modell-Krans per Alexa

Hintergrund

Das Thema Sprachsteuerung hat in letzter Zeit enormen Aufwind bekommen. Einsatzmöglichkeiten gibt es viele, ob im Auto – wo während der Fahrt Musik, Radio, Telefon oder die Navigation per Sprache gesteuert werden kann –  oder aber für Geräte mit beschränktem GUI wie z.B. Smart-Watches. Der Durchbruch für den Einsatz im privaten Haushalt ist letztendlich mit den neuen Geräten von Amazon (Echo), Apple und Google gelungen, welche viele Möglichkeiten bieten, über Sprache Entertainment, Dienstleistungen, das Smart-Home und vieles weitere zu steuern.
Seit der Einführung von Echo nimmt die Anzahl an Anwendungen (Skills) jeden Monat stark zu. Auch Unternehmen erkennen zunehmend die Chance, Dienstleistungen über die neuen Sprach-Schnittstellen anzubieten. Grund genug für mich, im Rahmen eines Gewinnspiels am Ausstellerstand der MT AG auf der DOAG Konferenz zum Thema Schnittstellen dieses neue Einsatzgebiet etwas näher zu untersuchen. Dafür soll per Spracheingabe ein Modell-Kran gesteuert werden. Als Sprachempfänger soll dabei der Echo Dot von Amazon verwendet werden.

Echo Dot / Alexa

Echo ist ein kleines Hardware-Gerät von Amazon, welches in zwei verschiedenen Versionen „Echo Dot“ sowie „Echo“ erhältlich ist. Die Echo Version bietet vor allem einen besseren Lautsprecher, ist aber auch deutlich teurer. Für dieses Projekt ist der Echo Dot vollkommen ausreichend, wichtig ist, dass er autark betrieben werden kann.

Die Geräte ermöglichen es, Befehle per Sprache entgegen zu nehmen, die Spracheingabe zu verarbeiten und bei Bedarf auch Antworten zu geben. Dies wird über eine eigene Software von Amazon realisiert, welche mit dem Namen „Alexa“ angesprochen wird. Die Sprachsoftware kann unabhängig vom Echo auch auf anderen Hardware-Geräten (z.B. einem Raspberry Pi) installiert werden.
Alle Befehle, die Alexa empfängt, werden zunächst zur Verarbeitung in die Cloud hochgeladen, wo das Gehirn von Alexa liegt. Damit besteht die Möglichkeit, die Intelligenz bzw. Erkennungsfähigkeit von Alexa permanent zu erweitern und zu verbessern, ohne dass die Geräte aktualisiert werden müssen.
Alexa kann geringfügig Abweichungen von den Sprachkommandos verstehen, ist aber generell noch nicht in der Lage, Sätze aus ihrem Kontext heraus zu interpretieren. Das Wortverständnis wird über Skills definiert.

Skills

Alexa bietet einige Befehle direkt mit der Auslieferung an. Das betrifft die Verknüpfung mit Diensten von Amazon (Musik spielen, Einkaufen etc.) oder auch Basisfunktionen wie Einkaufs- oder ToDo-Listen zu verwalten, Timer und Wecker zu stellen oder bestimmte Informationen abzufragen.
Um spezifische Funktionalität hinzufügen zu können, besteht die Möglichkeit, eigene Skills zu entwickeln und über Amazon anzubinden-/bieten. Dafür wird das Alexa Skills Kit verwendet, eine Sammlung von Self-Service APIs, Tools, Dokumentationen und Codebeispielen zur eigenen Entwicklung von Skills. Es gibt verschiedene Kategorien von Skills:

• SmartHome
• Flash Briefing
• Video-Streaming
• Custom für individuelle Anfragen.

In diesem Projekt wird der Custom Skill verwendet. In Zukunft wird es wahrscheinlich noch weitere Kategorien geben. In der kurzen Entwicklungsphase des Skills für das Projekt ist beispielsweise die Kategorie Video-Stream neu hinzugekommen.
Insgesamt existieren bereits 15.000 (Stand 07/2017) Skills in den USA für Alexa, wobei die Zahl noch rasant steigt. Viele Funktionen und Services wurden gerade erst eingeführt und stehen noch nicht weltweit zur Verfügung. Die Webseite zur Erstellung der Skills wurde ebenfalls in der kurzen Zeit der Entwicklung einige Male angepasst und um Funktionalitäten erweitern. D.h. man merkt, dass dieser Bereich gerade erst entsteht, aber mit großer Wucht auf den Markt drängt.

Bereitstellen eines Skills

Ein Skill agiert als eine Art Web-Service. Es ist möglich AWS Lambda dafür zu verwenden, oder aber einen eigenen, selbst gehosteten Web-Service zu verwenden.
Eine Lambda-Funktion ist eine Art „serverless Microservice“ und gehört zu der sehr beliebten neuen Kategorie Function as a Service (FaaS).
Amazon stellt im AWS Umfeld Ressourcen bereit, die das Ausführen von Diensten und Funktionen ermöglichen. Dabei ist die Hardware – auf der die Funktionalität läuft – für den Entwickler transparent. Es wird automatisch je nach Anforderung und Last skaliert. In diesem Modell muss der Service nur bezahlt werden, wenn er auch tatsächlich „benutzt“, also der Source-Code durchlaufen wird.
Falls eine AWS Lambda Function verwendet wird, muss man sich also nicht um die bereitstellenden Server kümmern, welche innerhalb des AWS-Umfelds liegen. Eine AWS Lambda-Funktion kann in Node.js, Java, Phyton oder C# geschrieben werden.
FaaS wird mittlerweile von allen großen Wettbewerbern angeboten (AWS Lambda, Google Cloud Functions, Microsoft Azure Functions, IBM OpenWhisk).
Ebenfalls kann ein beliebiger eigener Web-Service verwendet werden, welcher über das Internet angesprochen werden kann und Anfragen über HTTPS akzeptiert. Der Service kann in jeder beliebigen Sprache geschrieben sein.

Custom Skill

Der Custom Skill besteht aus einem Set von intents, welche die Kernfunktionalität der Anwendung beschreiben.
In unserem Beispiel ist das konkret „Links“, „Rechts“, „Hoch“, „Runter“ zur Steuerung des Krans.
Zu jedem intent gehört ein Set von sample utterances. Dieses Set besteht aus Sätzen, Phrasen und Wort-Kombinationen, die nachher vom Anwender geäußert werden können und auf konkrete intents mappen. Dieses Mapping wird innerhalb des interaction modell für den Skill definiert. D.h. je zahlreicher die hinterlegten Wortkombinationen sind, desto eher kann Alexa die Eingaben auf einen spezifischen intent mappen.
Der invocation name ist der Name, welcher den Skill identifiziert. Über diesen kann der Anwender später einen bestimmten Skill aufrufen. In unserem Beispiel ist das “ferngesteuerter Kran“. D.h. der Skill wird über Alexa folgendermaßen gestartet: „Alexa, starte ferngesteuerten Kran“.
Zur Erstellung der intents, sample utterances sowie dem dazugehörigen Mapping kann eine JSON Datei erstellt werden, oder aber direkt der Skill-Builder von Amazon verwendet werden (Beta Version, siehe folgenden Screenshot).

Ablauf eines Custom Skill

Der klassische Ablauf beim Custom Skill ist: Benutzer sagt etwas. Danach interpretiert Alexa das Gesagte und startet einen Request an den selbst geschriebenen Skill (in der Cloud). Der selbst geschriebene Skill gibt etwas zurück, was per Sprachausgabe oder grafisch ausgegeben wird. Wie ein solcher Ablauf bildlich aussieht, kann man hier sehen.

Schritte zum Anlegen eines Custom Skill

Hier eine Zusammenfassung der Schritte zum Anlegen eines Skills:

1. Zunächst ist das „Voice User Interface“ zu entwerfen. Dies sollte sorgfältig sowie mittels eines Flow Diagramms geschehen. In dem Diagramm sollten alle möglichen Anfragen des Anwenders sowie die Antworten des Skills enthalten sein.

• Daraus abgeleitet werden anschließend die intents, also die Kernfunktionen, die von dem Skill behandelt werden sollen.
• Siehe mehr dazu in dem Alexa Voice Design Guide
• Ebenfalls muss der Name sowie der invocation name (Name über den der Anwender den Skill in Alexa aufruft) erstellt werden

2. Anlegen des Skills über die Amazon-Developer-Plattform (Create a new skill)
3. Ausarbeiten des interaction model. Hier werden mögliche Sprachbefehle und Sätze des Anwenders auf die konkreten intents Die intends können optional Argumente haben (slots genannt). Werden diese Argumente nicht im Sprachbefehl genannt, fragt Alexa diese nach. Das wird innerhalb des dialog model festgelegt. Das interaction model kann entweder mit dem Skill-Builder erstellt werden (Beta-Version) oder aber die intents und zugehörigen utterances werden im JSON Format spezifiziert.
4. Schreiben des Codes für den Skill. Am schnellsten geht dies mittels AWS Lambda function. Dazu gehört die Anfragen von Alexa zu behandeln, eine card innerhalb der Antwort zurückzugeben, Build-in intents zu implementieren, Alexa Benutzer mit einem Benutzer innerhalb des eigenen Systems zu verlinken, Skill mit Adress-Informationen zu erweitern. Anschließend wird der Endpunkt des Skill innerhalb des Developer Portals eingetragen und der Skill mit einem Simulator oder einem Alexa-enabled Gerät getestet. Zum Schluss werden die Metadaten des Skills eingetragen, welche später innerhalb des Alexa Skill Store angezeigt werden.
5. Anschließend kann in einer Beta-Test Phase der Skill einer limitierten Benutzer-Gruppe zur Verfügung gestellt werden.
6. Nach Finalisierung aller Phasen wird der Skill zur Zertifizierung durch Amazon

One-Shot vs. Dialog Modell

Grundsätzlich wird bei der Kommunikation zwischen dem Benutzer und Alexa zwischen einem One-Shot Modell sowie einem Dialog-Modell unterschieden. Bei Ersterem wird der Alexa Skill sowie die Funktion in einem Schritt aktiviert. In einem Dialog-Modell wird zunächst der Skill geöffnet und anschließend einzelne Funktionen aufgerufen. Dabei muss auch nicht mehr der Prefix „Alexa“ vor jedes Kommando gestellt werden. Der Skill bleibt dabei so lange aktiv, bis er explizit wieder geschlossen wird.
In meinem Kran-Projekt soll ein Dialog-Modell verwendet werden. Der Benutzer öffnet den Skill zur Steuerung eines Krans und kann diesen anschließend über die Eingabe der einzelnen Kommandos steuern (z.B. links, rechts, hoch, runter).

Aus der Cloud zum lokalen Client

Die Kommandos, die von Alexa interpretiert werden, landen also zunächst auf einem Web-Service im Internet. Es muss nun eine Verbindung zwischen der lokalen Hardware (welche den Funksender Richtung Kran steuert) sowie dem Web-Service etabliert werden.
Folgend werden ein paar mögliche Alternativen untersucht.
1. Push-Verfahren
Der Web-Service kennt die lokale Hardware und leitet bei eingehenden Kommandos über Alexa eine Nachricht an die lokale Hardware weiter. Die lokale Hardware agiert dann als Server, mit einer bestimmten Schnittstelle (z.B. REST).
Nachteil:
Um auf die lokale Hardware zugreifen zu können, wird ein Endpunkt für die Verbindung benötigt. Das kann zum Beispiel über eine feste IP realisiert werden, welche der lokalen Hardware zugewiesen wird. Da diese aber in meinem Fall auf einem Messe-Stand steht, ist die Zuweisung einer festen IP ggf. etwas umständlich (über temporäre Dienste oder ähnliches).
2. Poll-Verfahren
Auf der lokalen Hardware wird über ein Polling-Verfahren auf den Web-Service zugegriffen (z.B. über einen REST-Client).
Nachteil:
Um möglichst geringen Zeitverzug zwischen Kommando und Umsetzung über Funk zu haben, muss das Polling mindestens sekündlich durchgeführt werden. Je nach Bandbreite bzw. Dauer der Vorführung ist das für den Messe-Stand keine gute Option.
3. Socket
Zwischen lokaler Hardware und Cloud-Service wird ein Socket geöffnet. Über dieses werden Änderungen/Kommandos direkt aus der Cloud an die lokale Hardware übertragen.
Nachteil:
Eine Verbindung muss permanent gehalten werden, dies ist ggf. mit dem verfügbaren Netz auf dem Messestand und evtl. Verbindungsabbrüchen nicht zuverlässig gewährleistet.
4. Publish/Subscribe
Die lokale Hardware registriert sich beim Broker (Cloud-Service) für ein bestimmtes Topic. Dieses wird nach Registrierung automatisch an die lokale Hardware übertragen. Das Verfahren bündelt alle folgende Vorteile und ist damit der ausgewählte Weg.

• Nur Übertragung bei anfallenden Daten
• Wenig Overhead für das Kommunikationsprotokoll
• Kein permanenter Verbindungsaufbau erforderlich
• Kommandos können fast in Echtzeit ausgeführt werden

Eine bekannte Implementierung dazu – genau für solcherlei Kommunikation – ist MQTT.

MQTT

Im Netz existieren verschiedene freie Broker, die verwendet werden können. Amazon stellt ebenfalls innerhalb des Entwicklungsportals mit AWS IoT eine erweiterte Implementierung bereit. In diesem Projekt wird  ein freier MQTT-Server aus dem Internet verwendet (iot.eclipse.org).
Die Eclipse-Paho Java-API wird zur Implementierung von Publisher und Subscriber verwendet. Die Verbindung zu einem Broker sowie das Senden/Empfangen von Nachrichten ist dabei sehr schnell erledigt.
Beispiel für das Senden von Nachrichten

Beispiel für das Empfangen von Nachrichten

Aufbau eines ferngesteuerten Krans mit Arduino

Zunächst war die Idee, ein bestehendes ferngesteuertes Modell zu nehmen und lediglich den Sender nachzubauen. Nach erster Analyse schien der Bereich Funktechnik etwas zu kompliziert, um schnell etwas bewerkstelligen zu können. Daher war der nächste Ansatz, einen Arduino zu verwenden und die Steuerung über Bluetooth zu realisieren.

Arduino

Ein Arduino ist eine kleine und relativ günstige Mikrocontroller-Umgebung. Ursprünglich zu Schulungszwecken entwickelt, hat sich um dieses Thema herum in kürzester Zeit eine sehr große Bastler-Gemeinschaft etabliert. Ein Arduino ermöglicht es, ohne viel Vorwissen in den Bereich der Elektronik und Mikrocontroller-Programmierung einzusteigen und zu fast allen Bereichen finden sich Beispiele und Anleitungen im Netz. Es gibt viele verschiedene Arduino-Versionen mit unterschiedlichen Funktionen. Für mein Projekt habe ich den gängigen Arduino Uno (R3) verwendet.

Mittels der Arduino IDE können Programme (Sketch) geschrieben und auf den Arduino übertragen werden. Ein weiterer Vorteil des Arduino ist, dass es bereits viele fertige „Shields“ gibt, welche auf den Arduino gesteckt werden können, so dass zusätzliche Funktionen bereitgestellt werden können. Ein Shield ist eine fertige Hardware, welche Chips und weitere Hardware-Komponenten beinhalten kann.

SainSmart L293D Motor Drive Shield

In unserem Beispiel muss sich der Kran natürlich bewegen können. Er wird über Motoren gesteuert, welche wiederrum über den Arduino angesteuert werden. Dazu wird in der Regel ein Chip verwendet, an dem die Motoren angeschlossen sind. Der Chip wiederum wird vom Arduino angesteuert. Ein klassischer Chip für kleinere Motoren ist der L293d Chip, welcher hier auch verwendet wird.
Zu dem Chip gibt es bereits ein fertiges Shield, welches die Steuerung von mehreren Motoren gleichzeitig erlaubt (auf dem Shield sind zwei L293d Chips verbaut, ein Chip kann zwei Motoren steuern). Verwendet wird in diesem Projekt das Shield von SainSmart, welches Baugleich zu dem Shield V1 von Adafruit ist.

Kommunikation über Bluetooth

Zur Kommunikation über Bluetooth wird ein HC-05 Modul verwendet, welches mit dem Arduino verbunden werden kann. Das Modul nimmt einem dabei die ganze Detail-Arbeit innerhalb des Bluetooth-Protokolls ab und mappt die Kommunikation auf die serielle Schnittstelle, welche über den Arduino ein-/ausgelesen werden kann.

Das fertige Modell

Nun, da alle Komponenten entwickelt sind, können diese in einen Modell-Kran integriert und das Projekt abgeschlossen werden.
Der abschließende Kommunikationsweg wird im folgenden Bild dargestellt: