Welcome to Daniels blog

Select one of the following projects or scroll down to the newest posts.

Roobert

a raspberry pi home robot


>> visit robert project page

Cobra robot

industry robot projects and restoration


>> see all cobra roboto posts

holoGaito

a holographic desktop assistant


>> visit the holoGaito project page

iGoBot

a GO game playing robot ... using a raspberry pi, opencv and gnugo


>> visit the iGoBot project page

Oculus Rift Unboxing / Seekrankheit

Wichtige Dinge benötigen offenbar meist 9 Monate von der Bestellung bis zur Lieferung ;-) Ganz in diesem Sinne ist nun das Development Kit der Oculus Rift Brille endlich eingetroffen.

Oculus Rift - Post aus California
Post aus California

Der Prototyp vom Herbst 2012 war ja noch von duct tape zusammen gehalten worden, aber die technischen Daten und Berichte der „Ausprobierer“ waren so viel versprechend, dass ich direkt das Development Kit bestellt hatte.

Oculus Rift - Alles gut verpackt
Alles gut verpackt

 Die jetzige Qualität und der Lieferumfang sind nun das komplette Gegenteil von duct tape. Vermutlich durch die hohe Anzahl der produzierten Kits konnte das Gerät höchst professionell umgesetzt worden. 

Oculus Rift - Hochwertiger Hartschalenkoffer
Hochwertiger Hartschalenkoffer

Es kommt nun in einem passgenauen Hartschalenkoffer daher und es liegen mehr als genug Standardkabel für HDMI, USB etc. bei.


Tolles Zubehör

Auch die Brille selbst wirkt wie ein fertiges, ladentaugliches Produkt – natürlich bis auf den Aufdruck „Development Kit“ :-)

Oculus Rift - Schaut eher wie ein ladenfertiges Produkt als ein Development Kit aus
Schaut eher wie ein ladenfertiges Produkt als ein Development Kit aus

Erste Eindrücke des mitgelieferten Tuscany-Demo sind beeindruckend immersiv. Zwar fällt die durch die „geringe“ Auflösung von 720p begründete Unschärfe sehr deutlich auf, aber das schwächt das Gefühl „vor Ort“ zu sein nicht besonders. Bei der für 2014 angekündigte Consumer-Version mit full-HD scheint diese Unschärfe ja deutlich geringer zu sein. Die Rift-Roller-Coaster-Demo ist ebenso erstaunlich.

Insgesamt habe ich bei den verfügbaren Demos für mich zwei Kategorien ausgemacht: Diejenigen, welche man sehr lange und beeindruckend real „besuchen“ kann. Und diejenigen, bei denen mir nach recht kurzer Zeit körperlich übel wird. An welchem  Effekt bzw. Unterschied dies liegt, habe ich noch nicht genau fest machen können. Ich tippe auf die Latenz zwischen Kopfbewegung und Bild, das korrekte Rendering eines validen 3D-Bildes und/oder wie stark man durch den Raum bewegt wird, statt eine feste Position zu haben.

Während ich die Tuscany-Demo minutenlang ohne Nachteile verwenden kann, stellt sich beim „Musem of the Microstar“ innerhalb von wenigen Minuten eine spürbare Seekrankheit ein. Beim ersten Mal habe ich das mal tollkühn ignoriert und auf einen Gewöhnungseffekt vertraut. Mit dem unangenehmen Ergebnis, dass mir 10 Minuten später körperlich so übel war, dass mich das noch die folgenden zwei Stunden deutlich verfolgt hat, bis Kopfschmerz und Übelkeit wieder weg waren. Schade eigentlich, denn das „Musem of the Microstar“ Demo ist schon eines der imposanteren.

Oculus Rift - Der Versuch, Museum of the Microstar durch die Brillen-Optik zu fotografieren
Der Versuch, Museum of the Microstar durch die Brillen-Optik zu fotografieren

Anschließend konnte ich schon eine erste eigene Applikation mit der Brille ausprobieren – das Ergebnis ist bereits viel versprechend.

Oculus Rift - Ein erster Blick in FireTouchVR
Ein erster Blick in FireTouchVR

Nach 20 Jahren wieder mit Virtual Reality gestartet

Eigene Hard- und Software für Virtual Reality zu erstellen, begleitet mich bereits seit den 1990er Jahren.

Leider waren während dieser Zeit keine erschwinglichen und dennoch akzeptabel funktionierenden Video-Brillen verfügbar waren. Was ich in die Hände bekommen konnte, war daher entweder selbst konstruiert - oder für zu viel Geld von zu schlechter Qualitität und verfügte über Blickwinkeln von gerade mal 32°.

Selbst konstruierter Virtual Realitiy Helm aus den 1990er Jahren
Mein erster, selbst erstellter VR-Helm mit Handschuh aus den 1990er Jahren. Die Auflösung betrug pro Auge 320x200 Pixel in Farbe - dafür aber bereits in stereoskopischem 3D. Das Headtracking erfolgte per Ultraschall.

Nun scheint mit Oculus Rift endlich der Durchbruch gelungen zu sein. Erfreulicher Weise werden die Developer Kits nun seit letzter Woche ausgeliefert. Mein im Herbst 2012 bestelltes Exemplar sollte ich daher nun hoffentlich bald in den Händen halten können. Mit über 100° Blickwinkel, einem eingebauten Motion-Tracker und einer zeitgemäßen Bildauflösung klingt das alles schon sehr verlockend :-)

Damit ich auch gleich voll loslegen kann, sobald die Oculus Brille eintrifft, bereite ich nun das Körper- und insbesondere Handschuh-Tracking vor.

Als Grundlage dazu dienen eine Kinect und ein Cyberspace-Handschuh aus den 1990er Jahren.

20 Jahre alter Cyberspace Handschuh bekommt neue Elektronik
Die alte und neue Hardware auf einen Blick

Dank des Kinect SDK von Microsoft war es recht einfach, das Körper-Tracking innerhalb weniger Stunden so umzusetzen, dass Kopf- und Hand-Positionen korrekt erkannt und visualisiert werden.

Die Elektronik des Handschuhs ist ebenfalls 20 Jahre alt und misst nur die Krümmung der Finger - nicht aber die Drehung im Raum. Noch dazu ist die Baugröße für heutige Maßstäbe unattraktiv groß.

20 Jahre alte Cyberspace Elektronik
Cyberspace-Elektronik aus den 1990er Jahren - groß und leider nur wenig leistungsfähig

Aktuell ersetze ich daher die Elektronik gegen eine auf Arduino Basis und spendiere dem Ganzen einen 9DOF Lage- und Bewegungssensor. 

Cyberspace Elektronik auf Arduino Basis
Die neue Elektronik im Test-Aufbau. Sieht auf den ersten Blick nicht sonderlich kleiner aus ;-) Aber am fertigen Handschuh selbst befindet sich später nur noch die kleine, rote Platine in der Mitte.

Auch die Messung des Lichtflusses durch die Glasfaser-Optik des Handschuhs kann der Arduino dank seiner analogen Eingänge prima übernehmen.

IR-LEDs zur Messung der Finger-Krümmung eines Cyberspace Glove
Als einzige Bauteile der ursprünglichen Elektronik bleiben die IR-LEDs und IR-Empfangsdioden zur Messung der Glasfaser-Krümmung erhalten. 

Hackathon 2012: Projekt Wortwecker - Teil 2

Bereits am zweiten Tag unseres Events hatten Dirk und ich den Großteil der elektronischen Schnittmuster für die verschiedenen physikalischen Lagen des Wortweckers erstellt. Wie erwartet machte das Passepartout für die einzelnen Buchstaben den meisten Aufwand, zumal wir noch ein laserfähiges Icon für die Weck-Funktion erstellen mussten.


Am dritten Tag konnten wir dann bereits die ersten Platten laserschneiden. 

Nachdem die erste Holzplatte mit den Montagelöchern für die jeweils 112 LEDs geschnitten war, konnte auch hier die Bestückung beginnen:

Dirk setzte die Leuchtdioden ein und verlötete die Anoden so, dass alle mit einander verbunden waren.


Dirk verlötet die LEDs in der Halterungsplatte

Anschließend galt es, an jede LED ein 30cm langes Kabel zu löten, welches später mit der Lochraster-Platine verbunden werden sollte. Hierbei teilten Dirk und ich uns die Arbeit auf: Die Kabel schneiden, abisolieren und zu verzinnen übernahm Dirk  - das eine Ende der Kabel an die Platine zu löten, war meine Aufgabe.  Das Anlöten der anderen Kabelenden an die Kathoden der einzelnen LEDs war dann gemeinsame Arbeit.


Viele viele Kabel!

Um bei dem ganzen Kabelwust zumindest ein wenig den Überblick zu behalten, verwendeten wir bei jedem achten Kabel eine andere Farbe als bei den vorherigen sieben. Dadurch musste an jedem Schieberegister-Chip das erste Kabel immer die Sonderfarbe haben, sonst war wohl etwas falsch gelaufen. 

In der Zwischenzeit beschäftigte Thomas sich damit, den Produktionsprozess der Platinen zu optimieren um sowohl Zeit zur sparen, als auch die Qualität zu steigern. 

Mitten im Arbeitsvorgang verweigerte der Lasercutter dann überraschend den Dienst und verlangte nach einem neuen Luftfilter. Da dieser aber nicht kurzfristig beschafft werden konnte, mussten wir die Arbeiten an dieser Stelle unterbrechen. Von da an konzentrierten wir unsere gesamte Energie darauf, die vier Elektroniken und Verkabelungen fertig zu stellen. 

Am Ende des vierten Tages hatten wir dann tatsächlich für jede der vier Uhren die Elektronik fertig gestellt, getestet und ge-bugfixed. 

Interessante und zum Teil überraschende Fehlerquellen gab es auch hier wieder ausreichend in Form von defekten LEDs, defekten Schieberegistern und kontaktlosen Lötstellen. Wiederum wären wir hier ohne Jens´ Oszilloskop aufgeschmissen gewesen. 

Hackathon 2012: Projekt Wortwecker - Teil 1

Im September war es dann soweit: Dirk, Jens und Thomas fanden sich ein, damit wir gemeinsam 4 Tage und Nächte lang Pizza essen, Cola trinken und basteln konnten.

Unser Ziel war es, dass am Ende jeder der vier Bastler einen fertigen Wortwecker mit nach Hause nimmt - also eine Uhr, welche die aktuelle Zeit in Form von Sätzen anzeigt. Dabei werden die Buchstaben durch einzelne LEDs mit entsprechendem Passepartout dargestellt.

Geplanter Funktionsumfang des Wortweckers:

•Anzeige der Uhrzeit
•Automatische Zeitstellung per Funkuhr
•Helligkeit der Leuchtdioden je nach Umgebungshelligkeit
•Weck-Zeit einstellbar
•Weck-Melodie definierbar

Als „Gehirn“ der Uhr wählten wir einen Arduino Uno

Arduino Uno mit Funkuhr-Modul
Arduino Uno mit Funkuhr-Modul

Insgesamt sind pro Wecker 112 LEDs verbaut, welche alle einzeln angesteuert werden möchten. Da der Arduino natürlich nicht über so viele Ports verfügt, muss noch eine entsprechende Schaltung zwischen Arduino und LEDs eingesetzt werden. Kern dieser Schaltung sind bei unserem Projekt 14 Stück TPIC6C595 Schieberegister pro Uhr. 

Ohne Plan läuft nichts...
Ohne Plan läuft nichts...

Da wir nicht nur ein reines Löt- und Bestückungs-Projekt durchführen wollten, entschieden wir uns für die Verwendung von Lochrasterplatinen statt geätzte Platinen zu designen. Eine Wahl, welche wir bei einem „nächsten Mal“ sicher überdenken würden ;-)

Tag 1

Los ging es am ersten Tag mit der Programmierung des Arduino, wobei dieser Tag eigentlich nur ein halber war, da wir erst am späten Nachmittag begannen und zu diesem Zeitpunkt auch erst zu dritt waren.

Während Dirk und Thomas die LED-auf-Worte-Übersetzung und die Beschickung des Schieberegisters vorbereiteten, konnte ich mich mit dem Auslesen des Funkuhr-Modules befassen.

Dirk und Thomas programmieren die Schieberegister
Dirk und Thomas programmieren die Schieberegister

Was mich zugegebener Maßen an den Rand des Wahnsinns getrieben hat. Der verwendete Funkuhr-Empfänger ließ sich nicht korrekt auslesen und verweigerte jede sinnvolle Zusammenarbeit. Einer Stunde und viele Test-Programme später probierte ich ein zweites Exemplar aus, und – aha – dieses funktionierte dann augenscheinlich. Also war wohl der erste Empfänger kaputt. Am nächsten Tag funktionierte dann aber auch dieser zweite Empfänger nicht mehr bzw. nur noch sehr sporadisch.

Am Ende stellte sich per Zufall heraus, dass das Notebook den Empfang der Uhr störte: Der Abstand der Uhr zum Notebook bestimmte, ob diese ein (funktionierendes) Zeitsignal empfangen konnte oder halt nicht.

Wenn die Funkuhr ausreichend weit vom Notebook entfernt ist, funktioniert sie plötzlich
Wenn die Funkuhr ausreichend weit vom Notebook entfernt ist, funktioniert sie plötzlich


Impressionen vom Schieberegister-Test-Arbeitsplatz

Tag 2 

Der zweite Tag startete mit den Arbeiten an der ersten Platine. Die Aufgaben waren die Verteilung der Bausteine und die optimale Verdrahtung der Lochrasterpunkte als Ersatz für Leiterbahnen. Im Nachhinein betrachtet liegt die Anzahl an Drähten und Bauteilen pro Platine wahrscheinlich knapp an der Grenze (oder auch darüber), was man noch per Lochraster machen kann oder sollte.

Die Platine wird bestückt..
Die Platine wird bestückt...

... und verlötet
... verlötet, und gemessen

Nachdem Jens und Thomas die erste Platine fertig bestückt und verlötet hatten, ging es an das Hardware-Debugging. Prima war dabei, dass Jens sein Oszilloskop mitgebracht hatte, denn die Schaltung verhielt sich überhaupt nicht so wie erwartet.

Auch hier zeigte sich nach langem Suchen, dass wir – wie schon bei der Funkuhr – einem Phantom nachgejagt waren.

Gut dass Jens sein Oszilloskop dabei hatte
Gut dass Jens sein Oszilloskop dabei hatte

Arduino und die Arrays

Offenbar initialisiert ein Arduino Programm ein Byte-Array auf dem Heap mit Nullen, während es auf dem Stack den Speicher bereit stellt wird, jedoch der vorherige Inhalt der betroffenen Speicherzellen unverändert bleibt. Das frühe Testprogramm mit ausschließlich statischem Array funktionierte daher wunderbar. Für den Test der fertigen Platine hingegen waren die identischen Code-Zeilen bereits in Methoden ausgelagert worden und verhielten sich daher anders. Aber wer soll so etwas erahnen? Da liegt es näher, nach Fehlern auf der umfangreich verdrahteten und verlöteten Platine zu suchen... und das dauert dann durchaus mal mehrere Stunden.