Hip Hop Hype – Der Gartner Hype Cycle 2014

Mitte August hat Gartner (http://www.gartner.com/newsroom/id/2819918) wieder seinen  Hype Cycle für Emerging Technologies veröffentlicht. Zum 20. Mal.

Dieses Mal steht der Weg zum Digitalen Business im Mittelpunkt. Und auf diesem Pfad sind sechs Stufen von Analog bis zu Autonomous zu durchlaufen.

NFC, Big Data und Cloud Computing stehen für die Stufe 4 „Digital Marketing“. 3D Drucker und Scanner, Internet of Things und Wearable User Interfaces auf Stufe 5 „Digital Business“.

Neu aufgenommen wurden dieses Jahr z. B. Software Defined Anything und Connected Home.

Gartner Hype Cycle 2014

Zum Vergleich, der Hype Cycle von 2013 findet sich unter: https://blogs.uni-due.de/zim/2013/08/26/hip-hop-hype-der-gartner-hype-cycle-2013/

 

Veröffentlicht unter Allgemein, Trends & Entwicklungen | Verschlagwortet mit , , , , , | Schreib einen Kommentar

Mit SVG und Javascript richtigen Strom erzeugen – eine grafische Animation des einschrittigen Übertrages nach Howard Aiken und Konrad Zuse.

Da am Ende etwas Buntes und Bewegliches herausgekommen ist, zeige ich es zuerst.

[iframe src=“https://www.uni-due.de/zim/burkhard.wald/svg2014/aiken6.svg“]

Die Herausforderung bestand darin, die grafischen Objekte mit elektrischen Eigenschaften zu versehen. Die Objekte sollen selbst wissen, ob sie sich berühren und sollen unter sich aushandeln, ob „Strom“ vom einem Objekt zu anderen übergeben werden soll. Und die Schaltelemente sollten natürlich im Bild anklickbar sein.

Am besten an dieser Stelle sollte ich mich entschuldigen, für die Möglichkeit, dass Sie als Leser und Betrachter das alles doch nicht so sehen und wahrnehmen, wie ich es mir gedacht habe. „Die Welt ist im Wandel“ könnte man mit der Elbenfürstin Galadriel aus der Tolkien-Welt sagen. In der Internet- und „Browser-Welt“ entstehen ständig neue Konzepte und Standards, die sich durchsetzen oder wieder im Nichts verschwinden. (Oder sie parken für einige Jahre oder Jahrzehnte in einer Warteschleife.) Um am Puls der Zeit zu sein, muss man daher immer die aktuellen Versionen der Web-Browser installiert haben. Mit meinem Artikel nutze ich ein Konzept und erzeuge zugleich eine Nachfrage nach der Unterstützung dieses Konzeptes.

Zunächst möchte ich aber erläutern, was die Zeichnung darstellt. Es geht um das maschinelle Addieren von Binärzahlen. Im Prinzip gehen Addiermaschinen – seien es mechanische, elektromechanische oder elektronische – ähnlich vor, wie wir es auch vom schriftlichen Addieren her kennen. Man stellt die Zahlen in einem sogenannten Stellenwertsystem dar, addiert dann zunächst die einzelnen „Stellen“ und muss eventuell noch pro „Stelle“ einen „Übertrag“ verarbeiten. Das ist unabhängig davon, ob man im Dezimalsystem, im Binärsystem oder in Hexadezimalsystem rechnet.

Schon die ersten Rechenmaschinen aus dem 17. Jahrhundert, die mit rotierenden Zahlenscheiben arbeiteten, brauchten eine besondere Vorkehrung um den Übertrag an die nächste Scheibe weiterzureichen. Eine besondere Schwierigkeit besteht in Situationen, wo ein Übertrag in einer Stelle, auch in der nächsten Stelle wieder einen Übertrag erzeugt. Nehmen wir z.B. die Addition 999999 + 1. Muss der Automat sich für diese Aufgabe mit den Überträgen von Stelle zu Stelle durchhangeln, oder kann er das in einem einzelnen Arbeitstakt bewerkstelligen?

Auch Howard Aiken und Konrad Zuse standen in der Mitte des letzten Jahrhunderts vor diesem Problem, als sie die ersten Computer konstruierten.

Der dargestellte Schaltplan geht auf Aiken zurück und ist dem Kapitel „Zuse, Aiken und der einschrittige Übertrag“ des Buches „Historische Notizen zur Informatik“ von Friedrich L. Bauer (ISBN: 978-3-540-85789-1) entnommen. Wir sehen die Addierschaltung für eine einzelne Stelle im Binärsystem. Es werden zwei Binärzahlen a und b addiert, die hier durch zwei Schaltergruppen a und b über Relais gesteuert werden. Die Relais sind auf der rechten Seite dargestellt. Am Anfang erhalten sie das Signal 0. Durch klicken auf die 0 wird zum Wert 1 umgeschaltet. Dann zieht das entsprechende Relais an. Außerdem kommt von rechts der Übertrag von der vorhergehenden Stelle des Binärsystems. Der Übertrag erfolgt in zwei Leitungen: Die untere ist genau dann stromführend, wenn ein Übertrag ankommt, und die obere genau dann, wenn kein Übertrag ankommt. Mit dem Schalter U kann man im Bild den Übertrag ein- und ausschalten. Dieser Schalter gehört nicht wirklich zu der Schaltung, die wir darstellen wollen. Er ist gewissermaßen ein Ersatz für die entsprechende (gleiche) Addierschaltung der vorhergehende Binärstelle. Unten links wird der Übertrag, der in der fokussierten Binärstelle berechnet wird, an die nächst höhere Stelle weitergeben. Durch klicken auf die beiden Eingänge für a und b und auf dem Schalter U kann man 8 verschiedenen Stellungen der Schaltung durchspielen. In der Mitte sieht man das Ergebnis der Summenberechnung für diese einzelne Binärstelle: Am Anfang ist es natürlich die 0.

Zuse verwendet in der Z3 eine Schaltung, die in jeder Stelle noch zwei weitere Relais benötigt.

[iframe src=“https://www.uni-due.de/zim/burkhard.wald/svg2014/z3.svg“]

Die Berechnung erfolgt in drei Schritten. Man beachte aber, dass auch hier wie bei Aiken, die Weitergabe des Übertrages nicht ein schrittweises Übertragen von Stelle zu Stelle ist. Nehmen wir eine Addition 1111 + 1 = 10000. Dann ergibt die xor-Verbindung von a und b in den ersten 4 Stellen jeweils den Relaisstand x=1. Kommt dann von rechts der Übertrag hinzu, wird er gleichzeitig an alle Stellen weitergeben und nicht Schritt für Schritt.

An einem Gymnasium in der Schweiz ist in einer Projektarbeit eine HTML-basierte Animation entstanden, die das Zusammenspiel mehrere Binärstellen darstellt. Siehe hier. Die Animation zeigt den „Stromfluss“ in Zeitlupe. In Wirklichkeit passiert das aber in Lichtgeschwindigkeit. Einen relevanten „Zeitverbrauch“ in der Schaltung hat man stattdessen durch die Trägheit der Relais. Das sollte man im Hinterkopf haben, wenn man diese und auch meine Schaltungen betrachtet.

Später kommt Zuse zu einer Schaltung mit Dioden. Das oben zitierte Buch stellt zwei Varianten gegenüber. In der ersten Publikation der Schaltung hatte sich offenbar ein Fehler eingeschlichen, welcher sich über mehrere Auflagen gehalten hatte. Das Informatik-Buch stellt die „richtige“ Schaltung daneben. Dummerweise ist auch diese Variante falsch.

Ich präsentiere eine 3. Variante, mit erneutem Anspruch auf Richtigkeit.

[iframe src=“https://www.uni-due.de/zim/burkhard.wald/svg2014/zuse3.svg“]

Kommen wir jetzt zu der Frage, wie die Bilder technisch realisiert wurden. Es lag nahe, für die Darstellung der Schaltpläne das XML-Format SVG für Vektorgrafik zu wählen. SVG wird heute von den aktuellen Versionen der Web-Browser unterstützt, sodass man kein besonderes Programm oder Plug-In zum Betrachten installieren muss. Die Browser verarbeiten die SVG-Datei in einer ähnlichen Weise, wie sie auch HTML-Dateien verarbeiten. Daher hat man hier die gleichen Möglichkeiten, mit Hilfe von Javascript als Programmiersprache Dynamik in ein Bild zu bringen. Das bedeutet:

  • Events (z.B. Mausklicken) können Javascript-Code zur Ausführung bringen.
  • Die Seite (HTML, SVG) wird im Speicher durch einen Objekt-Baum (DOM) dargestellt, auf den man mit Javascript zugreifen kann.
  • Javascript kann Eigenschaften vorhandener Seiten-Bestandteile verändern.
  • Javascript kann Seiten-Bestandteile erschaffen und entfernen.

Diese Möglichkeiten wollte ich nutzen, um zwei Ziele zu verfolgen:

  • Das endgültige Zeichnen eines Schaltplan sollte auf einer höheren anwendungsbezogenen Ebene erfolgen. Ich will also mit einfachen Befehlen Schalter Dioden und leitende Verbindungen platzieren können, ohne mich jedes mal wieder mit den SVG-spezifischen Details befassen zu müssen.
  • Und ich wollte richtigen Strom machen. Wenn sich zwei Objekte berühren, sollen sie als „verbunden“ gelten. Und wenn dann das eine Objekt „stromführend“ ist, soll sich diese Eigenschaft auf das andere Objekt automatisch übertragen.

Die Sache mit dem Strom schien zunächst nicht so schwierig zu sein. Was ist aber, wenn durch das Schalten eines Schalters ein Kontakt wieder gelöst wird? Dann müsste man die Stromübertragung zum Teil rückgängig machen. Man müsste also wissen, welches Objekt welchen anderen Objekten Strom übergeben hat; also eine Art Übertragungsrichtung. Ist das aber das richtige Konzept? Man kann sich Schaltungen vorstellen, die nach und nach den Strom auf weitere Objekte übertragen und dann schließlich auf ein Objekt stoßen, das schon über einem anderen Weg Strom bekommen hat. Wenn man jetzt etwas unterbricht, wie will man da noch eine Verlässlichkeit haben, welche Objekte wirklich vom Strom abgetrennt werden müssen und welche stromführend bleiben. Mein Fazit war „Strom übertragen“ geht gut, aber für „kein Strom“ kann man kein funktionierendes Übertragungskonzept ersinnen.

Um zu einer Lösung zu kommen, muss man sich einmal in richtigen Strom hineindenken. Die Weitergabe von Strom über einen leitenden Kontakt ist nicht ein einmaliges Event, sondern ein permanenter Vorgang. „Unterbrechen“ bedeutet daher nicht, dass eine Unterbrechung weitergeleitet werden muss, sondern dass die vorhandene Weiterleitung unterbrochen wird. Um dass zu erreichen habe ich mich entschieden, bei jeder Änderung in der Konstellation der Objekte (oder Schalterstellungen) erst einmal alles grundsätzlich wieder auf „aus“ zu setzen und jedes mal den Strom von den Stromquellen aus über die gegebenen Kontakte neu zu übertragen.

Es ist ein Datei mit Javascript-Code entstanden, die man in eine SVG-Datei einbinden kann. Hier ein kleines Beispiel für so eine SVG-Datei.

<?xml version=“1.0″ encoding=“UTF-8″?>
<svg version=“1.2″
baseProfile=“tiny“
viewBox=“0 0 20 4″
preserveAspectRatio=“xMidYMid“
fill-rule=“evenodd“ stroke-width=“0.05″
stroke-linejoin=“round“
xmlns=“http://www.w3.org/2000/svg“
xmlns:xlink=“http://www.w3.org/1999/xlink“
xml:space=“preserve“ onload=“init()“
>

<g visibility=“visible“ id=“Main“> </g>

<script type=“text/ecmascript“ xlink:href=“dynamische_schaltkreise.js“> </script>

<script type=“text/ecmascript“>
<![CDATA[

function init() {
var SP = new schaltplan(„Main“);
new quelle(SP,’W‘,3,3);
new schalter(SP,“a“,’O‘,“L“,3,3);
new verbindung(SP,“O“,5,2,6);
new verbindung(SP,“O“,5,4,6);
new schalter(SP,“b“,’W‘,“L“,13,3);
new dyn_text(SP,“O“,13,2,0,“0″,“1″);
SP.restart(); }
]]>
</script>

</svg>

Mit onload=“init()“ wird erreicht, dass als erstes nach dem Laden der SVG-Datei die Funktion init aufgerufen wird, in der wir den zu zeichnenden Schaltplan definieren müssen. Vorher haben wir einen leeren SVG-Gruppen-Knoten definiert, dessen Id „Main“ wir der schaltplan-Funktion übergeben. Hier ist das Beispiel im Bild. Es stellt eine einfache Wechselschaltung da, wie wir sie Zuhause in Diele, Keller oder Wohnzimmer haben. Logisch interpretiert ist es eine XOR-Schaltung.

[iframe src=“https://www.uni-due.de/zim/burkhard.wald/svg2014/wechsel.svg“]

Zum Weiterlesen empfehle ich den Programm-Code in der Javascript-Datei. Da ich damit rechnen muss, dass sich das einer anschaut, habe ich es mehrfach überarbeitet und glattgezogen und mit ausführlichen Erläuterungen versehen. Es ist eine „spannende“ Geschichte, in der es um Kommunikation und Vernetzung geht – wie aus dem prallen Leben. Der Programmierer und Blogger ist zufrieden und denkt sich: „Alles geschieht nach meinem Plan“. Im folgenden Bild sieht man ihn zusammen mit seinem Seelenverwandten Konrad Zuse.


(In Hünfeld, wo Zuse zuletzt gewohnt hat)

Weitere Anmerkungen

Instabile Schaltungen

Warum gibt es in der Natur Geräusche? Das ist gewissermaßen die Art der Natur mit instabilen Situationen klarzukommen: Die Natur macht daraus eine Schwingung. Ein einfaches Beispiel ist eine elektrische Klingel. Ein Magnet wird über einen Kontakt angesteuert. Zieht der Magnet an, wird die Stromzufuhr unterbrochen. Dann fällt der Magnet ab und der Stromkreis wird wieder geschlossen. In unserem Programm würde das zu einer Endlos-Schleife führen, mit der der Web-Browser als Interpreter des Programms nicht zurecht kommt.

Hazzards

Eine gewisse Unzuverlässigkeit von elektrischen Schaltungen ist in unserem Model ausgeklammert. Ein realer Schalter hat in der Phase des Umschaltens von 1 verbunden mit 2 zu 1 verbunden mit 3 eine kleine Übergangssituation, in der weder 1 mit 2 noch 1 mit 3 verbunden ist, oder in der gleichzeitig 1 mit 2 und 1 mit 3 verbunden ist. Man nennt das Hazzard oder Glitch. Hier sind zwei Schaltungen die prinzipiell gleich funktionieren. Man klicke vier mal auf den Schalter a: Dann nimmt die Schaltung vier verschiedene Konstellationen an. Die erste der Schaltungen hat aber die Eventualität in der Praxis nicht zu funktionieren. Beim zweiten Klick auf a könnte das Relais ungewollt abfallen. In der darauf folgenden Schaltung wird diese Unsicherheit überbrückt.

[iframe src=“https://www.uni-due.de/zim/burkhard.wald/svg2014/viertakter1.svg“ frameborder=“0″ scrolling=“no“]

[iframe src=“https://www.uni-due.de/zim/burkhard.wald/svg2014/viertakter2.svg“ frameborder=“0″ scrolling=“no“]

SVG in HTML einbetten

Zuletzt musste ich noch lernen meine SVG-Ergüsse in eine HTML-Dateien einzubetten. Bei den ersten Versuchen hat es problemlos geklappt, wenn ich einfach das <img>-Tag nahm, mit dem man auch Bitmap-Dateien einbindet. Doch da hatte ich noch keine Javascript-Dynamik in meinen Beispielen. Die Dynamik geht bei so eingebetteten Dateien leider verloren. Da die Inhalte unserer SVG-Dateien dynamisch mit einem Skript erzeugt werden, blieb ihre Darstellung folglich leer.

Die Lösung ist das <object>-Tag. Damit bindet man Medienobjekte ein, mit denen dann der Browser interagieren kann. Alternativ kann man auch das <iframe>-Tag verwenden. Für diesen WordPress-Blog hat sich das IFRAME als die praktikablere Lösung erwiesen. Das liegt aber daran, dass WordPress den HTML-Code nochmal filtert und verändert, um sein eigenes Konzept zu realisieren.

Lokalgeschichte

Auch an der Uni-Essen gab es einmal eine Zuse: eine Z25. Das war in vieler Hinsicht schon ein modernes Gerät auf der Basis von Transistorschaltungen. Sie konnte mit einem spezifischen Maschinencode aber auch schon mit der höheren Programmiersprache Algol programmiert werden. Als ich 1988 zum Rechenzentrum kam, Stand die Z25 ungenutzt im Rechnerraum an der Schützenbahn. Ich habe etwas recherchiert und mit pensionierten Kollegen gesprochen. Die Maschine wurde 1967 von der Abteilung Vermessungswesen der Ingenieurschule für Bauwesen mit Sondermitteln des Landes beschafft. Mit der Gründung der Gesamthochschule 1972 wurde die Fachhochschule in die Universität Essen integriert. Der Computer kam in die Henry-Dunant-Straße und wurde noch bis zum Ende der 70-er Jahre für die Programmierausbildung eingesetzt. Die immer noch funktionsfähige Maschine steht jetzt im Rechenmuseum Arithmeum der Universität Bonn und kommt bei Vorführungen zum Einsatz.

Veröffentlicht unter Code & Kernel, Tipps & Tricks, Trends & Entwicklungen | Verschlagwortet mit , , , , , | Schreib einen Kommentar

Integration einer Garagentorsteuerung in OpenHAB mittels Tinkerforge

Während des ZIM talks über Home automation und Datenvisualisierung wies Th. Eichstädt-Engelen vom OpenHAB-Projekt auf die mittlerweile gute Unterstützung seitens OpenHAB für die Module von Tinkerforge hin.

Inspiriert von seiner Anmerkung und durch diesen Beitrag wird im Folgenden exemplarisch dargestellt, wie eine Umsetzung in OpenHAB möglich ist. Als Anwendungsbeispiel dient eine Handfernsteuerung für ein Garagentor, welche durch Tinkerforge Module physikalisch integriert und letztlich über den Bus von OpenHAB angesprochen werden soll.

Hands-on

Folgende Utensilien werden dafür benötigt:

  1. Eine bereits gepaarte Garagentorsteuerung (möglichst ein Zweitgerät, ohne Garantie). Dieses Gerät muss im Wesentlichen über einen Schalter verfügen.
  2. Tinkerforge Master Brick,
  3. Tinkerforge Industrial Quad Relay Bricklet,
  4. 2 Kabel und
  5. ein Lötkolben.

Zunächst sind auf der Platine der Fernbedienung am Schalter die beiden aktiven Anschlüsse zu identifizieren. Dies lässt sich leicht feststellen, indem man sie probeweise mit einem Kabel überbrückt. An die beiden so identifizierten Anschlüsse des Schalters wird dann je ein Kabel gelötet. (Achtung: Dies geschieht auf eigene Verantwortung! Hierdurch kann schlimmstenfalls die Fernbedienung unbrauchbar werden!) Die Enden dieser beiden Kabel werden dann einem der vier Schaltrelais auf dem Industrial Quad Relay Bricklet zugeführt (im Bild sind dies das rote und das grüne Kabel im ersten bzw. im der Kamera zugewandten Relais).

tinkerforge_setupBild: Industrial Quad Relay Bricklet, Master Brick und die Platine einer vorhandenen Fernsteuerungen

Das Industrial Quad Relay Bricklet wird am Master Brick befestigt und letzterer mittels USB angeschlossen, nämlich an den Rechner, auf dem der so genannte „Brick Daemon“ laufen muss.

Software – Brick Viewer und Brick Daemon

Zur Umsetzung ist neben OpenHAB auch Software von der Tinkerforge-Website notwendig. Zunächst wird mit dem Tinkerforge Brick Viewer die ID des Industrial Quad Relay Bricklets ausgelesen und notiert, z.B.: ifd. Diese ID wird später für die Konfiguration von OpenHAB benötigt.

Danach wird auf einem von OpenHAB erreichbaren Server der Brick Daemon installiert. Dies kann natürlich auch derselbe Server sein, auf dem OpenHAB läuft.

Konfiguration in OpenHAB

In OpenHAB wird nun zunächst die Tinkerforge Binding so konfiguriert, dass der Brick Dämon per IP auf dessen Standard-Port erreicht werden kann:

####### Tinkerforge Binding #######
tinkerforge:hosts=127.0.0.1

Listing openhab.cfg (Auszug)

Jetzt sind zwei Items zu definieren. Das erste Item (hier: QR1) repräsentiert das physikalische Tinkerforge Relais, das zweite Item Garage wird benötigt um den physikalischen Druckschalter einer Fernbedienung über den Touchscreen eines Smartphones zu simulieren. In OpenHAB wollen wir für die Nutzung von Touchscreens nur ein „button pressed“ Event auswerten, nicht aber zusätzlich ein „button released“ Event. Also wird beim Antippen des Switch-Items Garage das Relais über das Switch-Item QR1 aktiviert und nach 1,5 Sekunden – über eine Zeitverzögerung gesteuert – wieder unterbrochen. Die subid referenziert das benutzte Relais; hier ist es der erste von insgesamt vier Stück, also relay0.

/* Garage */
Switch QR1    "QR1" {tinkerforge="uid=ifd, subid=relay0"}
Switch Garage "Garage" <garagedoor>

Listing Items (Auszug)

Zur Realisierung der Aktivierung und zeitverzögerten Deaktivierung des Schalters wird noch eine Regel hinzugefügt.

rule "Garage"
when
Item Garage received command
then
QR1.sendCommand(ON)
Thread::sleep(1500)
QR1.sendCommand(OFF)
// Sure it is off? Wait...
Thread::sleep(1500)
// ...and send again...
QR1.sendCommand(OFF)
end

Listing Rules (Auszug)

Schließlich wird die interaktive Schaltfläche als Button Element in die Sitemap eingefügt.

 Switch item=Garage mappings=[ON="Door"]

Listing Sitemap (Auszug)

Für Näheres sei auf die OpenHAB-Binding-Doku zu Tinkerforge verwiesen.

Im Ergebnis zeigt das OpenHAB UI dann einen interaktiven Button, bei dessen Druck die Handfernbedienung 1,5 Sekunden lang über das Relais geschaltet wird.

tinkerforge_openhab_ui

Bild: OpenHAB UI (hier mit Button für eine Garagentorsteuerung)

Fazit

Das hier beschriebene Vorgehen ist rein experimenteller Natur und empfiehlt sich nur sehr bedingt zur Nachahmung. Eine derartige Modifikation einer Fernbedienung führt sehr wahrscheinlich zum Verlust des Garantieanspruchs! Außerdem kann eine Fernbedienung grundsätzlich beim Löten beschädigt werden. Eine derartige Schaltung (hier: Relais) kann natürlich auch über viele andere Mechanismen und dann ggf. preiswerter realisiert werden, z.B. über den GPIO-Port eines Raspberry Pi oder über Schaltkreise hinter einer seriellen Schnittstelle. Als Einstieg in die Ergänzung von OpenHAB um Tinkerforge ist eine solche Schaltung aber gut geeignet, da man sehr schnell zu Ergebnissen gelangt.

Veröffentlicht unter Code & Kernel, Tipps & Tricks | Verschlagwortet mit , , | Schreib einen Kommentar

Horizon Report 2014 auf deutsch – die neuesten Trends im E-Learning

Der Horizon-Report 2014 wurde auch dieses Jahr wieder vom Multimediakontor Hamburg ins Deutsche übersetzt. Dieser Report enthält die E-Learning-Technologien, die in den nächsten fünf Jahren im Bildungsbereich eine wichtige Rolle spielen und wird alljährlich von den US-Fachverbänden Educause und New Media Consortium herausgegeben.

Die sechs ausgewählten Technologietrends sind:

  • Zeithorizont ein Jahr oder weniger:
    • Flipped Classroom
    • Learning Analytics
  • Zeithorizont 2–3 Jahre:
    • 3D Printing
    • Games und Gamifizierung
  • Zeithorizont 4–5 Jahre:
    • Quantified Self
    • Virtuelle Assistenten

Learning Analytics und 3D Printing wurden auch schon im letzten Jahr aufgeführt, sind aber jetzt auf der Zeitachse weiter nach vorne gerutscht. Games und Gamification bleiben beim Zeithorizont von 2-3 Jahren. Der Hype um MOOCs hat sich dagegen gelegt.

Gamification hat auch das ZIM im letzten Jahr sehr beschäftigt. Entstanden ist daraus Campus Isles (www.uni-due.de/campusisles), ein Spiel in dem Erstsemester, aber auch andere Interessierte, spielerisch den Campus der UDE kennen lernen können.

Weiterhin gehören zu den Schlüsseltrends die zunehmende Verbreitung der Sozialen Medien aber auch die Aus- oder Verwertung von von Lernenden erzeugten Daten.  Analytics.

Eine Zusammenfassung des Reports findet sich beim MMKH (http://www.mmkh.de/news/horizon_report_2014_die_deutsche_ausgabe_ist_online-1.html) und der komplette Report unter: http://www.mmkh.de/fileadmin/dokumente/Publikationen/2014-Horizon-Report-HE_German.pdf

Zum Vergleich die Trends der zwei letzten Jahre:

 

Veröffentlicht unter Allgemein, Trends & Entwicklungen | Verschlagwortet mit , , , , , | Schreib einen Kommentar

Sprich Freund und tritt ein – Sprachausgabe für den Raspberry Pi mit eSpeak und SVOX-pico

Embedded Computer sind je nach Einsatzgebiet häufig nicht mit Bildschirmen oder Displays ausgestattet. Wenn sie aber in wechselnden Umgebungen mit DHCP eingesetzt werden, ergibt sich häufig die Anforderung einmal schnell die bezogene IP-Adresse herauszufinden. Natürlich lässt sich dieses Problem komfortabel mit DynDNS lösen, wenn der Rechner auch wirklich mit dem Internet verbunden ist. Ansonsten bleibt immer nur die Suche nach einem neuen Netzwerkgerät im Webinterface des Routers.

Diese Anforderung hatte ich selber ursprünglich für einen mobilen Roboter, der sich in wechselnden Umgebungen bzw. WLAN-Netzen bewegen konnte, und per Webinterface bedient wurde. Um den Roboter initial zu finden musste die IP-Adresse bekannt sein.
Aber auch für Zwecke der Heimautomatisierung eingesetzte Mini-Rechner müssen nicht immer mit Display betrieben werden. Für die Ausgabe seltener Störungen bietet sich das Audio-Interface, also die Soundkarte, als preiswerte und stromsparende Alternative an.

[hana-flv-player video=“http://www.pediaphon.org/~bischoff/videos/pioneer1.flv“
width=“400″
height=“auto“
description=“Activemedia Pioneer 3AT Roboter“
player=“5″
clickurl=“http://www.dr-bischoff.de/videos/andreas_video_galerie.html“
clicktarget=“_blank“
autoload=“true“ autoplay=“false“
loop=“false“ autorewind=“true“
splashimage=“http://www.pediaphon.org/~bischoff/videos/pioneer1.jpg“
skin=“mejs-ted“
/]

Mein mobiler Activemedia Pioneer 3AT Roboter mit Sprachausgabe 2006 FernUni in Hagen, damals realisiert mit MBROLA

Computergenerierte künstliche Sprachausgabe wird mit sogenannter Text-to-Speech-Software TTS realisiert. Diese Software setzt mit Hilfe von umfangreichen Aussprache-Lexika oder Heuristiken (Regeln) für die Zielsprache geschriebenen Text zunächst in eine Abfolge einzelner Laute (Phoneme) um. Die einzelnen Laute, bzw. deren Kombinationen werden entweder von einem Menschen bei der Erstellung der Software eingesprochen oder ebenfalls synthetisch (Signalsynthese oder Formantsynthese) erzeugt. Neuere Systeme basieren auf einem umfangreiche Wortschatz an von einem Menschen gesprochenen Worten, so das eine nahezu natürliche Sprache generiert werden kann. Selbst die Herausforderung eine natürliche Sprachmelodie (Prosodie) zu erzeugen, scheinen moderne kommerzielle Systeme zu meistern. Nun erfordert so eine hochqualitative Sprachdatenbank sehr viel Speicherplatz und ist aufwändig und teuer zu produzieren. Trotz allem gibt es im Open-Source-Bereich brauchbare und auch schlanke freie TTS-Programme. Eine sehr Ressourcen-sparende TTS-Software ist eSpeak. Diese Software wurde ursprünglich auf einem Acorn RISC_OS Computer, also auch auf einer ARM-Architektur, entwickelt und eignet sich durch Ihre Kompaktheit, Ausführungsgeschwindigkeit und geringen Speicherbedarf besonders für Embedded Systeme. Außerdem unterstützt eSpeak über 20 Sprachen. An die Aussprache muss man sich etwas gewöhnen, sie ist aber verständlich.

Die auf dem Raspberry-Pi verwendete Debian-Variante Rasbian unterstützt eSpeak out-of-the-box.

Mit

sudo apt-get install espeak

ist die Installation erledigt. Die Ausgabe testen kann man testen, nachdem man das Audiointerface auf den Klinkenstecker per Alsamixer umgestellt hat. Default ist beim Rasberry PI Audioausgabe über HDMI. In /etc/config.txt kann das aber auch fest eingestellt werden.

sudo amixer cset numid=3 1

espeak -vde „hallo welt hier spricht der räspberri pei“

So hört sich das Ergebnis an:

Wenn keine Option -w angegeben wird, gelangt die Ausgabe direkt an das Audio-Device /dev/dsp .

Höhere Sprachqualität mit SVOX-Pico

Eine Alternative mit der derzeit besten Sprachqualität im Open-Source-Bereich stellt die SVOX-Pico-TTS-Engine dar.

So klingt es dann mit svox-pico:

Vielleicht kommt dem einen oder anderen Nutzer die Stimme bekannt vor. SVOX-Pico ist die in den Android-Versionen 2.1-2.3 eingesetzte Default-Sprachausgabe. Die neue, ab der Version 4.0 von Google für Android eingesetzte, TTS-Engine ist leider Closed-Source. Die SVOX-Pico TTS-Engine ist derzeit auch die Default-Engine für meine Wikipedia-Sprachausgabe Pediaphon und unterstützt neben Englisch (UK und US), Deutsch, Französisch auch Italienisch und Spanisch in hoher Qualität. Auf der Pediaphon-Seite können Sie übrigens auch online eigene Texte in Sprache umwandeln.

SVOX-Pico liegt als Open-Source vor, ist auf diverse Linux-Varianten portiert worden und lässt sich z.B. unter Ubuntu einfach mit sudo apt-get install libttspico-utils installieren. Für Raspbian muss das Paket selber kompiliert werden. Alternativ können Sie mein Debian-Paket für Raspbian ARM einfach herunterladen (MD5-Hash: b530eb9ff97b9cf079f622efe46ce513) und mit den Kommandos


apt-get install libpopt-dev
sudo dpkg --install pico2wave.deb

auf dem Rasberry Pi installieren. Das libpopt-dev ist ebenfalls erforderlich.
Mit

sudo amixer cset numid=3 1
pico2wave --lang=de-DE --wave=/tmp/test.wav "hallo welt hier spricht der räspberri pei"; play /tmp/test.wav;rm /tmp/test.wav

können Sie die Sprachausgabe testen.

Mit

sudo apt-get remove pico2wave

kann man das Debian-Paket auch wieder sauber deinstallieren.
Wer selber kompilieren möchte, muss neben know how etwas Geduld mitbringen.
Um die Quellen zu kompilieren ist neben automake auch das libtool erforderlich:

git clone -b upstream+patches git://git.debian.org/collab-maint/svox.git svox-pico
apt-get install automake libtool libpopt-dev
automake
./autogen.sh
./configure
make all
make install

Alternativ kann man auch ein direkt ein Debian-Paket bauen, dass auch sauber wieder aus dem System entfernt werden kann.
Ich habe zusätzlich für mein Binary die GCC-Optionen
-mcpu=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard
passend für den Raspberry Pi angepasst, damit auch die Hardware floation-point Unterstützung genutzt wird.

Um dann z.B. beim Bootvorgang automatisch die IP-Adresse des Pis zu sprechen, habe ich in der /etc/rc.local folgende Kommandos eingefügt:

/usr/bin/amixer cset numid=3 1
/usr/bin/espeak -vde "meine ei pie Adresse lautet $_IP"

Sicherlich lassen sich noch eine Menge anderer sinnvolle Anwendungen für eine Sprachausgabe auf dem PI finden. Mit seinen Sensoren kann der Pi auch als ein preiswertes Hilfsmittel für Blinde-Nutzer eingesetzt werden.

Veröffentlicht unter Allgemein, Tipps & Tricks | Verschlagwortet mit , , , | Schreib einen Kommentar