Hallo,
ich habe mit einem Arduino UNO und einem Ultraschall-Sensor ein
Entfernungsmessgerät gebaut, welches dann per Knopfdruck die Entfernung
auf einem LC-Display anzeigt.
Jetzt hab ich mir gedacht es wäre doch nett wenn ich irgendwie auch noch
eine Sprachausgabe bekommen könnte. Nach Benutzung der Suchfunktion und
Google sieht es so aus als müsste ich noch zusätzlich ein Board haben
das mit dem Audio umgeht. Ich will nicht wirklich was fertiges kaufen,
dehalb hab ich mir gedacht ich könnte vielleicht den Arduino an meinen
Raspberry Pi hängen und es darüber ausgeben lassen, das schränkt die
Mobilität natürlich stark ein, aber die Sprachausgabe ist eher als
Lernprojekt gedacht als eine dauerhafte Erweiterung.
Hat jemand Ansätze/Ideen?
Henrik
Henrik S. schrieb:> Jetzt hab ich mir gedacht es wäre doch nett wenn ich irgendwie auch noch> eine Sprachausgabe bekommen könnte.
Ist im Prinzip überhaupt kein Problem, PWM-Ausgänge hat der Atmel genug.
Alles, was du an Hardware brauchst, ist ein Filter und ein Verstärker,
wobei das beides natürlich auch eine Einheit bilden kann, da
NF-Verstärker heutzutage ja sowieso fast alles OVs sind und mit
entsprechender Beschaltung des Rückkopplungszweiges problemlos
gleichzeitig als Filter dienen können.
Ein Problem bleibt allerdings: Die Samples brauchen recht viel Platz.
Zwar reichen für Sprachausgabe 8 Bit Auflösung mit 11kHz Samplefrequenz
völlig aus, aber auch das sind eben 11KByte/s. Da paßt nicht allzu viel
von in einen AVR, in die größten gerade mal ca. 20 Sekunden.
Du brauchst also höchstwahrscheinlich externen Speicher, z.B. eine
SD-Card.
Also für eine Variante die nur mit dem AVR funktioniert dachte ich mir
folgendes:
Wenn ich eine Entfernung von z.B. 1,23 cm habe liest der code die erste
Zahl (1), sagt "eins", liest das Komma, sagt "Komma" etc...
Die zahlen von 0 - 9 und das Wort "Komma" kann ich in 1 sec packen, es
muss ja nicht gut klingen.
Wie würde ich das denn Code-Technisch realisieren? Also wie sag ich dem
Controller, dass er die erste Ziffer der Zahl lesen soll und wie gebe
ich dann das wort "eins" aus?
Henrik
>Also wie sag ich dem>Controller, dass er die erste Ziffer der Zahl lesen soll und wie gebe>ich dann das wort "eins" aus?
Vergiss dein Projekt einfach. Das ist drei Zehnerpotenzen zu hoch
für dich.
>>Also wie sag ich dem>>Controller, dass er die erste Ziffer der Zahl lesen soll und wie gebe>>ich dann das wort "eins" aus?>> Vergiss dein Projekt einfach. Das ist drei Zehnerpotenzen zu hoch> für dich.
Also meine erste Frage ziehe ich erstmal zurück, ich bleibe einfach bei
ganzen Zahlen, d.h. ich brauche "nur" einen Weg, das Wort "eins" über
einen Lautsprecher auszugeben. Wie gehe ich das an?
Henrik
Einfachste und flexibelste Variante dürfte das abspielen einzelner
wav-Files von einer SD-Karte sein. Für Arduino gibt es einige Beispiele
für wav-Player.
Vom Prinzip her habe ich das auch so für die Ausgabe von Telemetriedaten
gemacht, allerdings in BASCOM, mit entsprechenden Dateien: 1.wav, 2.wav,
100.wav, Komma.wav, Spannung.wav...., die dann aufgrund der
aufbereiteten Daten nacheinander aufgerufen werden.
Ist das WAV Format dazu nicht unnötig komplex? Ich würde es mit Rohdaten
versuchen, die einfach nur noch richtig getaktet in den D/A Wandler
übertragen müssen.
Da fällt mir gerade ein: Es gibt doch MP3 Player Chips mit SD Interface,
die man über eine serielle Schnittstelle dazu anweisen kann, eine Datei
abzuspielen. Damit wäre es sicher am einfachsten - wenn man an so einen
Chip heran kommen kann.
Danke erstmal für die ganzen Antworten!
Ich würde das Ganze, wenn möglich, ohne zusätzliche Hardware (also
zusätzliche Chips) realisieren. Ist das denn möglich?
Henrik
Hi
>Ich würde das Ganze, wenn möglich, ohne zusätzliche Hardware (also>zusätzliche Chips) realisieren. Ist das denn möglich?
Ganz ohne wird es nicht gehen. Du willst ja schließlich auch etwas
hören.
Vielleicht kannst du hierauf aufbauen:
http://www.atmel.com/Images/doc1456.pdfhttp://www.atmel.com/Images/avr335.zip
MfG Spess
Das generelle Problem ist ja die Größe der Audiodaten. Spiel doch ein
bisschen mit Audacity oder einem ähnlichen Programm rum um zu ermitteln,
bis zu welcher Sampelrate die Sprachausgabe noch erträglich ist.
Passen dann die Audiodaten und das Programm in das Flash ist das Problem
gelöst. Die alten analogen Telefone waren von der Bandbreite auch
bescheiden und dennoch konnten wir uns verständigen.
Grüsse
Stefan Frings schrieb:> Ist das WAV Format dazu nicht unnötig komplex?
Der Overhead von PCM-Wav ist kaum der Rede wert, das bissel
IFF-Struktur-Gerümpel und der kleine Header fallen im Vergleich zu den
Nutzdaten kaum in's Gewicht, selbst bei relativ kleinen Dateien, wie sie
hier in der Anwendung benötigt werden würden.
Gegen die geringe Platzersparnis steht der Vorteil, daß sich die
WAV-Dateien sehr leicht mit jedem beliebigen Audioprogramm erzeugen und
ggf. auch nochmal bearbeiten lassen.
Also ich persönlich würde hier zwar sicher auch drüber nachdenken,
RAW-Daten zu verwenden, aber mich letztlich wohl doch lieber für in
einen WAV-Container verpackte entscheiden.
Wenn's wirklich eng werden sollte im Speicher, würde ich eher darüber
nachdenken, einen einfachen Dekompressor (z.B. für ADPCM) zu
implementieren. Sowas kann man nämlich auch in einen WAV-Container
packen und dabei ca. 25..50% des Platzes bei kaum merklichen
Qualitätsverlust sparen.
Hallo,
wenn zur Ausgabe eine Roboterstimme ausreichend verständlich ist, gibt
es schon seit Urzeiten Lösungen, die ca. 8..16 Kilobyte groß sind.
Zwei Probleme tun sich auf:
* Es handelt sich um Abandonware, herrenlose Software ohne Quelltext
* Kann nur englisch, beim Versuch der Deutschanpassung klingt's immer
noch englisch
Jemand bei Github hat sich dem Problem mit dem fehlenden Quelltext zum
Glück angenommen, allerdings für eine Portierung auf 32 Bit - das ist ja
keine Kunst!
Er/sie hat die Binärdateien disassembliert und decompiliert, es handelt
sich nunmehr um C-Quelltext.
Ich habe seinen/ihren Quelltext weiter entschlackt und das Programm in 4
(Windows-)Teilprogramme von < 8 KByte Größe aufgeteilt, von denen man
für eine Ausgabe von Zahlen nur das 3. Teilprogramm für den Arduino aka
AVR compilieren muss: Es rechnet Phoneme in PCM-Waveform um. Eine
Sampletabelle von reichlich 1 KByte ist drin v.a. für die Zischlaute,
während 3 Sinusgeneratoren per DDS für den Ton (der Vokale) sorgen.
So kommt man ohne externen Speicher aus. Die Phoneme sind nur wenig
länger als geschriebener UTF-16-Text. Das erspart es, menschenlesbaren
Text auf dem AVR in Phoneme übersetzen zu müssen, das kann man mit dem
Windows-PC tun.
Siehe http://www.tu-chemnitz.de/~heha/Mikrocontroller/Sprache/#2
Aha, wieder was gelernt, danke!
Gibt's schon lange, nur zu finden war's für mich nicht, weil's eben
kein Text-To-Speech ist (was hier auch gar nicht nötig erscheint)
sondern LPC: https://de.wikipedia.org/wiki/Linear_Predictive_Coding
Da muss jemand die Wörter (am PC) einsprechen, und mit etwas Glück
kling's dann akzentfrei deutsch, bis auf die Kompressionsartefakte
natürlich. Oder man nimmt die vorgesprochenen (englischen) Fragmente,
die Teil der o.a. Software ist.
Was ich aus der angegebenen Quelle nicht erfassen konnte: Wie sieht es
hierbei mit dem Flash-Speicherbedarf aus? Also wieviel Kilobyte fix für
den Dekompressor und wieviel Byte/Kilobyte im Mittel pro Silbe?
Das könnte man in der readme.md des Github-Projekts angeben. Auch die
Abkürzung LPC auftrieseln, meist ist's Local Procedure Call.
>Aha, wieder was gelernt, danke!>Gibt's schon lange, nur zu finden war's für mich nicht, weil's eben>kein Text-To-Speech ist (was hier auch gar nicht nötig erscheint)>sondern LPC: https://de.wikipedia.org/wiki/Linear_Predictive_Coding
Die Umsetzung des Projekts ist eine enorme Leistung. Kaum einer würde
glauben, dass man eine LPC-Dekoder mit den ganzen notwendigen
Muliplikationen auf einem AVR umsetzen kann.
Umso erstaunlicher ist, dass der ursprüngliche Code von "Text and
Speech" 1978 stammt.
https://de.wikipedia.org/wiki/Texas_Instruments_LPC-Sprachchips
