Entscheidungsfindung - Technologie:
Ergebnis der Analyse war die Wahl des Frameworks “Rhasspy” und das Arbeiten mit dem Container-Dienst “Docker”.
Diese Wahl ist darauf begründet, dass mit Rhasspy auf dem Raspberry Pi und in der Sprache “Deutsch” gute Ergebnisse erzielt werden konnten.
Das Arbeiten mit Containern resultierte daraus, dass über das Nutzen von Images das spätere Bereitstellen der Software erleichtert werden kann.
Außerdem lässt sich dort relativ einfach mit festgelegten Versionen von Software arbeiten.
Dadurch kann verhindert werden, dass der Sprachassistent zu einem späteren Zeitpunkt nicht mehr wie in der Entwicklung konfiguriert arbeitet oder gar überhaupt nicht mehr installierbar ist.
Die Aussicht war den festgelegten Anforderungen mit den gewählten Technologien bestmöglich gerecht zu werden und diese dadurch erfüllen zu können:
Erste Iteration:
In der ersten Iteration wurde mit Containern von folgenden Diensten gearbeitet:
- Dem Sprachassistent Rhasspy
- Der Nachrichten-Broker Mosquitto, der das MQTT-Protokoll ausführt
- Das Programmiert-Tool Node-RED, welches ermöglicht mit Flows, Nodes und der Scriptsprache Javascript die zu entwickelnden Skills umzusetzen
- Die Musik-Abspiel-Anwendung Music Player Daemon, mit welcher es möglich ist Radio-Webstreams auf dem Raspberry Pi wiederzugeben
Images der auf dem Raspberry Pi laufenden Container:
Name | Link auf Docker Hub | Verwendete Version |
---|---|---|
Mosquitto | arm32v6/eclipse-mosquitto | 2.0.11 |
Node-Red | nodered/node-red | 2.0.6 |
Music Player Daemon | easypi/mpd-arm | latest |
Rhasspy | rhasspy/rhasspy | 2.5.11 |
Verwendete Technologien innerhalb von Rhasspy:
Bereich | Name der Technologie |
---|---|
Audio Recording | PyAudio |
Wake Word | Raven |
Speech to Text | Mozilla DeepSpeech |
Deutsches Sprachmodell für Deepspeech | AASHISHAG’s deepspeech-german |
Intent Recognition | Fsticuffs |
Text to Speech | NanoTTS |
Audio Playing | aplay |
Dialogue Management | Rhasspy |
MQTT | Extern (Läuft nicht im Rhasspy Container) - Mosquitto |
Zweite Iteration:
Die Verwendung der Weckwort-Erkennung Rhasspy Raven, welches darauf ausgelegt ist mit personalisierten Weckwörtern zu arbeiten, verlief nicht ideal.
Die Annahme war, dass durch das Nutzen von verschiedenen Stimmentypen (Junge Frau, Mittelalte Frau, Alte Frau, Junger Mann, Mittelalter Mann und Alter Mann) eine gute Erkennung von nicht eintrainierten Stimmen und Personen ermöglicht wird.
Dies stellte sich allerdings als Fehlannahme heraus.
Zusätzlich hatte Rhasspy Raven sogar Probleme von der Erkennung von Frauenstimmen die eigentlich eintrainiert waren.
Hiermit konnten die bestimmten Anforderungen nicht erfüllt werden.
Daraus resultierte die Wahl einer anderen Weckwort-Erkennung.
Für das Projekt war es wichtig, ein bestimmtes Weckwort (“MaxMax”) nutzen zu können.
Gleichzeitig musste die Wahl trotzdem noch den Open-Source Aspekt des Projektes befriedigen.
Durch Tests fiel die Wahl dann auf Rhasspy Pocketsphinx welches zwar als besonders flexibel gilt, gleichzeitig aber im Vergleich zu anderen Lösungen nur eine moderate Leistung in der Erkennung bietet.
In Wechselwirkung mit der Wahl des Weckwortes konnten hier trotzdem zufriedenstellende Ergebnisse erzielt werden.
Um verschiedene in den Anforderungen bestimmten Skills zu implementieren wurde im im Verlauf des Projektes die Nutzung von der Lampe und dem Erschütterungssensor nötig.
Hierfür wurde zusätzlich noch die Verwendung eines Containers des Dienstes zigbee2MQTT notwendig, um die externen Komponenten ansprechen zu können.
Die veränderten oder zusätzlich hinzugefügten Komponenten der zweiten Iteration sind hier gelb makiert:
Images der auf dem Raspberry Pi laufenden Container:
Name | Link auf Docker Hub | Verwendete Version |
---|---|---|
Mosquitto | arm32v6/eclipse-mosquitto | 2.0.11 |
Node-Red | nodered/node-red | 2.0.6 |
Music Player Daemon | easypi/mpd-arm | latest |
Rhasspy | rhasspy/rhasspy | 2.5.11 |
zigbee2mqtt | koenkk/zigbee2mqtt | 1.21.1 |
Verwendete Technologien innerhalb von Rhasspy:
Bereich | Name der Technologie |
---|---|
Audio Recording | PyAudio |
Wake Word | Rhasspy Pocketsphinx |
Speech to Text | Mozilla DeepSpeech |
Deutsches Sprachmodell für Deepspeech | AASHISHAG’s deepspeech-german |
Intent Recognition | Fsticuffs |
Text to Speech | NanoTTS |
Audio Playing | aplay |
Dialogue Management | Rhasspy |
MQTT | External - Mosquitto |
Entscheidungsfindung - Weckwort:
Wie wurde der Name und das Weckwort “MaxMax” gewählt?
Viele Sprachassistenten arbeiten mit einem Namen als Weckwort.
Dies ist gerade in der Projekt-Domäne von großer Bedeutung (Siehe nichtfunktionale Anforderungen: NF-020 bis NF-024), da es hilft einem sprechenden Gerät einen Namen zuordnen zu können um es zu personifizieren und damit als weniger abschreckend zu empfinden.
Gleichzeitig sollte der Name des Sprachassistenten dem Weckwort entsprechen, um die späteren Nutzer nicht unnötig zu verwirren oder zu überfordern.
Das Weckwort muss gut auszuprechen sein und auch von der Weckwort-Erkennung gut erkannt werden:
Erste Überlegungen gingen dazu “Max” als Name und Weckwort zu verwenden.
Gerade das “x” im Namen erzielt gute Erfolge in der Erkennung und kommt gleichzeitig in der deutschen Sprache nicht so oft vor.
Jedoch gibt es den Namen “Max” in Deutschland doch häufiger, also war dies keine entgültige Lösung.
Durch die Wiederholung des Namen (“MaxMax”) konnten im Test gute Erkennungs-Erfolge (gerade mit Rhasspy Pocketsphinx) erzielt werden und es war ein Weckwort geschaffen, was so im deutschen Sprachgebrauch nicht vorkommt.
Gleichzeitig lässt sich das Weckwort gut aussprechen und es ähnelt dem Wort “Mama”, was eines der ersten Wörter ist welches Kleinkinder in Deutschland lernen.