Sprachsteuerung mit Pocketsphinx

[Kuzl]

Hallo zusammen,

wie von Rince in diesem Beitrag http://forum.fhem.de/index.php/topic,13058.75.html gewünscht, mache ich hier nochmal einen extra Thread auf. Die Idee war mit Pocketspinx, welches auch von der Sprachsteuerung Jasper verwendet wird, eine Sprachsteuerung für FHEM zu entwickeln.
Tobt euch aus Jungs

Viele Grüße
Kuzl

[Rince]

Mercy
Pocketsphinx ist eine reine Spracherkennung.
Eine Verarbeitung erfolgt daher nicht.

Mein Vorschlag für das Modul ist, als Endprodukt den erlannten Text in einem Reading stehen zu haben, analog zu Dirks Android App.
Dann ist es für den User egal, ob er Sprache per Dirks App oder Pocketsphinx erkennen lässt.

Einige Info bezüglich der Installation gibt es auf der Projektseite von Jasper.
Bei Gelegenheit böte sich ein Copy Paste an.

Da des öfteren die Frage nach passenden Mikrofonen gestellt wird:
http://www.wolfsonmicro.com/media_centre/item/wolfson_audio_card_from_element14_-_high_definition_audio_for_the_raspberry/

Dabei handelt es sich um eine für den RasPi gedachte Soundkarte, die für knapp 40€ gleich 2 Mikros eingebaut hat. Ich habe es aber noch nicht selbst getestet.


Alternative:
Julius
http://de.wikipedia.org/wiki/Julius_%28Software%29

[Kuzl]

So war auch meine Idee.
Man muss dann nur einmal seine Befehle festlegen und für FHEM ist es egal, ob sie von der App oder direkt vom Raspi kommt.
das sollte dann eigendlich gar nicht so schwer sein oder?
ich hab zwar keinerlei Erfahrung mit Spracherkennungssoftware am Rasperry Pi aber man sollte ja eigentlich nur die Konsolenausgabe für Pocketspinx auf FHEM mappen müssen glaube ich.

Rince hast du es bei dir schon installiert / etwas rumprobiert?

[Rince]

Noch nicht.
Habe nur mal einige Tage mit lesen dazu verbracht.

Ich denke, zunächst besorge ich mir diese Wolfson Soundkarte.


Edit:
Habe bei Amazon mal eine bestellt.

Wird von http://www.squeezeplug.eu/ ebenfalls unterstützt. Damit denke ich macht das soweit auf jeden Fall Sinn

[Rince]

Pocketsphinx braucht entsprechende Modelldaten um Sprache entsprechend erkennen zu können.

Es gibt ein älteres Modell in Deutsch:
http://sourceforge.net/projects/cmusphinx/files/Acoustic%20and%20Language%20Models/

Und wohl auch neuere:
http://www.voxforge.org/home/forums/other-languages/german/updated-12k-word-16khz-sphinx-model-available#W6LVFS765_peN-4O4RIhTA

Wenn ich es richtig verstehe, kommen die Modelle von Voxforge. Die Community dort scheint auch bereit zu sein, eigene Sprachsamples zu integrieren, bzw. zu verarbeiten. Auf diese Art und Weise kann quasi Pocketsphinx besser werden.


Oh, und dieser Thread ist auch lesenswert:
http://www.voxforge.org/home/forums/other-languages/german/testing-german-with-pocketsphinx-hardly-no-hits#fg_4QzT7HUheSrpIN7Z_iw
Hier geht es darum, dass man mit 16 KHz aufnehmen muss.


Ich werde mich jetzt mal da etwas einlesen:
http://cmusphinx.sourceforge.net/wiki/tutorial

[Rince]

ich hab zwar keinerlei Erfahrung mit Spracherkennungssoftware am Rasperry Pi aber man sollte ja eigentlich nur die Konsolenausgabe für Pocketspinx auf FHEM mappen müssen glaube ich.

Ja und nein
Die Konsolenausgabe mappen ist eigentlich unnötig. Pocketsphinx und Sphinxbase sind so gesehen nicht fertige Programme, sondern Frameworks.
Sind aber Beispielprogramme dabei. Es sollte einfach sein, die Ausgabe so gleich direkt an fhem zu schicken. Dann erspart man sich die Umleiterei

Letztlich sieht es so aus, dass wir als fhem Modul gar nicht viel brauchen.
Wir müssen vor allem einen Guide schreiben Pocketsphinx zu installieren, eine eigene Pocketsphinx App schreiben (bzw. bei einer vorhandenen die Ausgabe von der Konsole an fhem schicken, z.B. per Telnet)
Unser Modul muss dann unsere Pocketsphinx App nonblocking starten und ein paar Readings bereitstellen.

Klingt easy.

Die spannenste Frage im Moment, die sich mir stellt, ist eigentlich, was für ein Wörterbuch und welche Grammatikfiles wir benutzen wollen.

Hier wäre jetzt der Input der Community gefragt:

Wir können die Files von VoxForge nutzen, ggfs. auch unsere eigenen Sprachsamples hochladen und integrieren lassen.
Der Vorteil ist, dass man so zu einem ziemlich großen Wortschatz kommt.
Wenn man mal etwas diktieren will, könnte das schlauer sein (wobei es dafür eigene Projekte gäbe).
Andererseits könnte ich mir vorstellen, dass dies durchaus auch länger zum bearbeiten braucht.

Alternativ könnten wir hier ein eigenes Vokabular hochziehen.
Ist halt mit Aufwand verbunden, weil wir alles selber from scratch basteln müssten. Inkl. unserer eigenen Voice-Samples.
Dafür dürfte es aber in der Anwendung schneller gehen, da weniger Daten durchsucht werden müssen.


Ich denke, rein praktisch, sollten wir mit dem aktuellen VoxForge Modell anfangen und uns mit der dortigen Community kurzschließen. Hat den Vorteil, dass wir gleich loslegen können.

Dann sehen wir schon, wie das läuft.


Aber dennoch würde mich die Meinung der Anderen hier interessieren, so es, außer dir Kuzl, noch jemand gibt den das Thema interessiert

[Kuzl]

Wow du hast dich ja gleich mächtig informiert

ich werd mir heute abend mal alles durchlesen

Meiner Meinung ist es auch Sinnvoll über ein "zweigleisiges" Modul nachzudenken; ähnlich wie Text2Speech.
Also dass man Pocketspinx als offline- und die Google spracherkennung als onlinevariante bereitstellt, da die ja bekanntlich auch gar nicht so schlecht funktioniert. .... aber eins nach dem anderen

Ich bin gespannt wie die Aufnahmequalität bei dir wird

[Rince]

Das dürfte prinzipiell gehen.
fhem Modul:
Ruft externes Programm auf (per Variable steuerbar: welches Programm, Kommunikationsparameter mit fhem, z.B. IP Adresse und Passwort)
Stellt Reading zur Verfügung:
Letzten 5 Sätze, Metadaten (Sprecher, Stimmung) (so als grobe Idee betrachten bitte), kompatibel zu Dirks Readings, ggfs. könnten wir das mit Dirk absprechen auch)

Externes Programm:
Pocketsphinx

Google API (also Steuerprogramm dafür), oder das ct Skript...

Solange diese beiden Programme die Readings identisch übertragen, sind sie beliebig Austauschbar. Wir müssen nur die Kommunikation mit fhem definieren. Aber da man ja letztlich das auch oft hintereinander kann, ist eine spezielle Reihenfolge oder so eigentlich auch unnötig.

[Kuzl]

Ich denke als erster, einfacherer Schritt könnte man das c´t script mal in ein Modul umwandeln, da das ja schon ein lauffähiges ist
(muss natürlich etwas gestutzt werden, antworten soll man dann ja über Text2Speech)
Das ist ja im grunde die Google Spracherkennung oder?
wenn das soweit funktioniert und die Readings etc. drin sind kann man Pockeshinx hinzufügen, das ja weitaus komplexer ist als das c´t ding.

Ich denke das wäre der sinnvollste weg, da man so schon mal einige Fehlerquellen ausschließen kann

[Rince]

Die Wolfson Karte ist da
Lade mir grade das Image runter. Gut, dass immer ein RasPi in der Gegend liegt
http://www.element14.com/community/community/raspberry-pi/raspberry-pi-accessories/wolfson_pi

Selbiges ist nötig, da die Karte einen Kerneltreiber benötigt, der nicht im normalen Repository enthalten ist bis jetzt. Und der Treiber ist Kernelversionsabhängig. Nun gut.

Erster Eindruck:
Zwiespältig.
Die Karte wird auf den Erweiterungsheader gesetzt. Daneben ist eine Bohrung (P5), 4-Polig, ohne aufgelötete Pins. Das Wolfson Teil hat hier etwas längere Stifte, die quasi in die Bohrlöcher passen sollen. Ob das geht, weiß ich nicht. Das muss wohl der Test in Kürze zeigen

@Kuzl
Kann man auch.

Das c´t Skript hat aber 3 Nachteile:
1. Sox läuft immer im Hintergrund mit um zu erkennen, ob Sprache ankommt. Muss mal sehen, wie das bei Pocketsphinx gelöst ist.

2. Die Sprache wird dann vom Mplayer in ein passendes Format konvertiert und einfach nach Google geblasen. Ich würde auf jeden Fall die Aufnahmen auf eine Ramdisk legen, sonst wird die SD Karte nicht alt.
Hatte ich damals aber auch schon beschrieben. Dann flutscht es auch viel besser

3. Die Erkennung läuft bei Google. Für Neurotiker ungeeignet


So. In 3 Minuten ist das Image da, dann geht es weiter

[Rince]

@Kuzl
Für Google:
http://www.raspberrypi.org/forums/viewtopic.php?f=37&t=9487
und:
https://gist.github.com/anonymous/3023698



Weiter gehts:
Image auf die Karte drauf
Karte rein, Netzwerkkabel dran und testweise mal ein SPDIF Kabel an die Wolfson


pi
raspberry

Hier etwas Lesestoff:
http://www.element14.com/community/community/raspberry-pi/raspberry-pi-accessories/wolfson_pi/blog/2014/03/14/can-you-hear-the-wolfson-calling-setting-up-and-using-the-wolfson-audio-card


Demnach:
./SPDIF_playback.sh
und dann:
ls
mplayer 15-<tab>

Klingt gut
Da kommen aus meinem alten Logitech Z680 ja wirklich Töne



Ich mache jetzt hier weiter:
https://sites.google.com/site/observing/Home/speech-recognition-with-the-raspberry-pi

[Zephyr]

Hallo zusammen,

eine Sprachsteuerung und Sprachausgabe hinzubekommen erscheint mir gar nicht so das große Problem zu sein. Andere Open Source Projekte scheint es genügend zu geben, die sowohl die Erkennung und Umsetzung in Text als auch die gesprochene Ausgabe von Texten tätigen.

Viel interessanter als dieses -anscheinend bereits gelöste- Problem interessiert mich, wie man auf hinreichend intelligente Art und Weise eine Steuerung von FHEM hinbekommt. Generisch funktioniert das sicher problemlos: "<Temperatur> um <Gradangabe> im <Wo> <rauf|runter>setzen"
Wie gehe ich aber damit um: "Setz die Temperatur runter" oder "Bitte nicht so warm" oder "im Wohnzimmer die Temperatur runterregeln"...
Meiner Meinung braucht es dazu doch eine KI, die auf Schlüsselworte reagiert und so lange nachfragt, bis alle Infos zusammen sind.

Ist DAS nicht die eigentliche Schwierigkeit?
Eine Sprachein- und Ausgabe anhand eines bestehenden Projektes bekommt man doch leichter hingeklöppelt...

... meint
Zephyr

[Rince]

Wenn man damit noch nie gespielt hat, ist es spannend.

Was du meinst, hat Kuzl schon geschrieben:
http://forum.fhem.de/index.php/topic,17409.0.html

Das, was da dabei rausgekommen ist, geht schon ziemlich in die Richtung die du möchtest

[Zephyr]

Ist doch aber auch alles nur viel zu generisch...
Das Pattern wird zwar -irgendwie- aufgebaut. Aber da fragt nix nach, bis alle Infos vollständig sind.

[Rince]

Na ja,
was du meinst ist ein Sprachdialogsystem.
Ich teile deine Meinung, dass es noch ein weiter Weg ist. Aber der Ansatz von Kuzl geht zumindest schon in eine gute Richtung.
Fehlende Infos könnten ja weiter abgefragt werden.

Mach doch mal einen Thread zum Thema Sprachdialogsystem auf, dann plaudern wir da weiter, ist das ok?


Edit sagt:
Schau dir mal VoiceXML an, genauer diese Erläuterung:
http://meiert.com/de/w3/Voice/Guide/

[Zephyr]

Mach doch mal einen Thread zum Thema Sprachdialogsystem auf, dann plaudern wir da weiter, ist das ok?

Done: http://forum.fhem.de/index.php/topic,22838.0.html