Sprachausgabe umgestellt auf espeak

Da die NSLU2 wegen zu geringer Rechenleistung und zu wenigen USB-Ports wohl einem "richtigen" Mainboard weichen wird, wurde an der bereits im Sourcecode integrierten Sprachausgabe weiter gefeilt. Konkret: festival wurde aufgrund ständiger Probleme mit der library entfernt und durch espeak ersetzt. Die Umstellung war in nur wenigen Schritten erledigt. Außerdem ist es nun ein eigenständiger Thread, der während des Sprechens im Hintergrund läuft und die Bedienung der GUI weiterhin möglich ist – so wie man es erwarten  sollte. :-) Auch wird bei neuen Sprachbefehlen, eine möglichweise gerade aktive Sprache sofort gestoppt und mit der neuen unmittelbar begonnen.

Ton-Beispiele gefällig? So klingt das ganze auf Englisch:

 

Und es gibt auch – was bei Open Source nicht ganz so häufig in guter Qualität anzutreffen ist – eine deutsche Sprachausgabe. Diese klingt dann so:

 

 

Die bisherige, recht schlecht zu verstehende Hardwarelösung wird demnach dann auch bald entfallen. Die Lautsprecher mit Verstärker werden natürlich weiterhin genutzt werden können.

[330 Aufrufe]

Anschlussmöglichkeit zum Laden und für externe Stromversorgung hinzugefügt – und einen Kurzschluss

Da das ewige An- und Abklemmen der Stromversorgung vom bzw. an den Akku immer recht umständlich ist und es auch nett wäre, wenn man die Roboter-Akkus "von außen" aufladen könnte, wurden zwei Buchsen hinzugefügt und entsprechend mit zwei Schaltern verabelt. Diese decken erst einmal die Haupt-Stromversorgungsakkus (12V) ab. Die 24V-Stromversorgung für die Laserscanner wird ggf. auch noch um Buchsen und Schalter erweitert.

 

Als erstes wurde eine praktische Stelle für die Schalter und Buchsen ausgewählt…

…dann die Schalter und Buchsen korrekt verkabelt…

…dann doch noch einmal darüber nachgedacht. Und dann noch mal ein Schaltplan skizziert…

…und noch mal alles geändert:

 

Es folgte ein erster Test. Eingeschaltet…nicht passiert…ausgeschaltet…Stecker geprüft…

…Sicherungen überprüft…

Das war also ein satter 10 Ampère-Kurzschluss. Immerhin:  Allles heil geblieben (bis auf die Sicherung). Das Sicherungskonzept hat sich also schon mal bewährt. :-)

Nach langer, wirklich langer Suche stellte sich nun heraus, dass zwei (nicht beschriftete) hier Stromstecker vertauscht waren:

Wie man in dem Bild sieht, sind zwar die Buchsen beschriftet, aber die Stecker noch nicht alle. Das wurde nach dem Foto dann nachgeholt. Und siehe da: Nun funktionierte es wie gewünscht. Als letztes wurden noch die Umschalter beschriftet, die die folgenden Zustände nun schalten:

  • Stromversorgung des Roboters über die Buchsen über eine externe Spannungsquelle (Netzteil)
  • Stromversorgung des Roboters über die eingebauten Akkus
  • Laden der Akkus über die Buchsen über eine externe Spannungsquelle (Netzteil)

Und so sieht das abschließend aus:

 

[305 Aufrufe]

Einbau des micromag3 Sensors (3D Kompass)

Um eine möglichst genaue Lageerkennung des Roboters zu ermöglichen, wurde auf das micromag 3-Achs-Magnetfeldstärken-Messgerät von PNI zurückgegriffen. Als von Magenetfeldern möglichst ungestörten Ort auf dem Bot wurde die Stelle zwischen den Laserscannern gewählt (möglichst weit weg von den Motoren). Weiterer Vorteil: Es ist genau die Mitte und damit der Drehpunkt des Bots. Also als erstes mal wieder raus mit einem Laserscanner…

 

…und die Platine verkabelt und mit Distanzbolzen zwischen den Scannern montiert:

 

Verbunden wurde das Modul per Flachbandkabel an den Atmel-Controller, der das Auslesen übernimmt. Angesprochen wird der Sensor übrigens via SPI. Den Sourcecode dazu gibt es – bequem per git auscheckbar – hier (direcs/direcs-avr/micromag.c und .h).

Das ist dann auch an diesem Screenshot rechts unten bereits zu erkennen:

[0 Aufrufe]

Verkabelung der Laserscanner, Motorboards und Sicherungen

Nach der NSLU war jetzt die Verkabelung der Laserscanner an der Reihe.

Vorher bekam die NSLU2 noch einen Ein-Aus-Taste spendiert (hier zu sehen die Lochbohrung in der Konsole) und die Motorboards wurden mit 12V versorgt:

   

Nun aber die Verkabelung der Laser (inklusiver Sicherungen):

Unterhalb der Laserscanner wurden die Kabel einigermaßen gebündelt, damit nichts "lose rumfliegt":

Auch die Akkus können jetzt auch an ihren vorgesehenen Platz. Erst auf der rechten Seite…

…dann auf der linken:

 

Und zum Schluss ein wenig "Showtime":

[0 Aufrufe]

Einbau und Verkabelung der NSLU2

Das Innenleben der "gepimpten" NSLU2 wurde an diesem Tag auf den Roboter montiert:

 

Die rote Platine oberhalb der NSLU2 ist ein Spannungsregler (auf 5 V). Nun das ganze noch mit Stromversorgungsleitungen versehen und bei der Gelegenheit den Stromverbrauch geprüft:

 

Damit es keine Kurzschlüsse bzw. Verbindungen der Platinen zueinander gibt, wurden diese mit (kurzerhand selbstgesägten) Kunststoff-Unterlegscheiben von den Distanzbolzen isoliert:

[364 Aufrufe]

Sprachausgabe für den Bot

Ein Roboter der nicht sprechen kann? Das geht gar nicht… ;-) Also wurde das Sprachmodul sp03 von Devantech erworben. Dieses ist per RS232 und per I²C ansteuerbar. Die zu sprechenden Texte (text to speech) werden mit nur wenigen Befehlen im ASCII-Format an das Modul gesendet.

 

Da das Modul vom Hersteller ab Werk nur mit einem Piezo-Speaker ausgestattet ist, wurde es in ein preiswertes Lautsprecherset mit integriertem Verstärker vom lokalen Elektromarkt eingebaut. Eine Sub-D-Buchse für die serielle Schnittstelle wurde ebenfalls integriert:

[0 Aufrufe]

Einbau des Atmel-Controllerboards, der Stromverteilung und der Konsole

Nun kommt das "Kleinhirn" des Roboters zum Einbau: Das Atmel-Controllerboard (Atmel 2560 Prozessor, 16 MHz, 256 kiB Flash-Speicher, 8 kiB RAM, 4 kiB EEPROM u.v.a.m.). Hier links oben im Bild:

Hier das "Power-Board" von der aus alle Komponenten mit Strom versorgt werden und im nächsten Bild sind die Module am Ziel:

Und so sieht das ganze dann fertig aus:

Auf dem folgenden Bild sieht man bereits die Verbindung der Motorcontrolboards mit dem Atmelboard per Flachbandkabel. Auf dem letzen kam dann noch ein hübsches Alu-Lochblech mit zwei "Vandalismus"-Tastern, einer 12V- und einer 24V-LED sowie dem Not-Aus-Schalter hinzu:

[0 Aufrufe]

Einbau der Motorcontrol-Boards

An diesem Tag wurden die Motorcontrol-Boards eingebaut. Als Untergrund dient eine weiche Kunststoffplatte aus dem Baumarkt, die sich per Cutter zuschneiden lässt und eben nicht leitet. Mit etwas Feingewühl ist sie aber eben noch hart genug, dass man noch  3mm-Gewinde reindrehen kann; z.B: für Abstandsbolzen:

Abstandsbolzen kamen ebenfalls in den "Boden" des Roboters um darauf dann die Kunststoffplatte zu montieren.


Damit ist sichergestellt, dass die Platine weit genug von den leitenden Aluprofilen entfernt ist:

[311 Aufrufe]

Rückbau mrs1 – R.I.P.

Da vom alten Roboter mrs1 so einige Teile der Elektronik benötigt werden, musste er kurzer Hand "dran glauben". Hier die Fotos des Rückbaus:

Schau mich bitte nicht so an! Ich werde es kurz und schmerzlos machen.. ;-)

 

 

Übrig blieb lediglich das Untergestell mit den Motoren und ein bißchen "Material". Wer weiß, wofür es noch mal gut ist…

 

 

 

[296 Aufrufe]

Umrüstung einer Linksys NSLU2, Cross compiling der Software

Hier der Zwischenstand der Umrüstung einer NSLU2 von Linksys:

Diese soll künftig anstatt des Laptops den Roboter als "PC" steuern. Der vollständige Umbau ist im Menü links unter "Fotos" zu sehen!

 

Nur soviel:

Der NSLU2 wurde zu einem Debian Linux verholfen, sie wurde um drei auf insgesamt fünf USB-Port "aufgerüstet" und mit WLAN versehen. Außerdem wurde "mal eben" (siehe auch Zeit zwischen dem letzen Blog-Eintrag und diesem!) die komplette Software per cross compiling für den NSLU2-Prozessor (Intel ARM XScale IXP420) umgewandelt. Natürlich musste die Software dabei auch noch "nicht-GUI"-ready gemacht werden; lässt sich also jetzt auch auf der Console aufrufen (ARM und Linux!) und übers Netz (LAN oder WLAN) steuern! Qt for Embedded Linux sein Dank!

 

Das heißt, das vollständige Qt-Programm direcs kann nun auf drei Arten verwenden werden

  • als GUI-Anwendung auf einem "normalen" PC
  • als Konsolen-Anwendung auf einem "normalen" PC
  • als Konsolen-Anwendung auf einem ARM-Prozessor – cross compiling Umgebung vorausgesetzt!

Steuerbar ist das Ganze per Umgebungsvariable vor Ausführen des make-Befehls.

[0 Aufrufe]