Building a home robot: Part 1 - introduction and head

(see all parts of "building a home robot")

Since I was a child and saw the tomy omnibot I was fascinated about robot companions. In the following years I took some tries to get or build one – for example the Sony Aibo in 2001 or my Cobra Robot.

Some weeks ago I started my first serious project of a self driving, self charging home robot - including things like face detection and voice output.

My girlfriend was not sure if it would be a little bit scary to live together with a home robot. So I decided to create a first prank design for the robot head especially for her ;-)


(A scary prank design created from old animatronics parts)

The real head will be much more cute and abstract, using a small monitor instead of physical eyeballs.

As the robot “brain” I choose a Raspberry PI 3 because it is small, fast and with low power consumption.  Other reasons were: cheap and native camera, hardware connections via the PIO port and the available official touchscreen monitor.

To create most of the body parts I want to use my 3D printer.

In the past I often used 3d editor programs like Autodesk 3D Studio or Cinema 4D – but never real CAD programs. After some research for a low cost but useful CAD program I found OpenSCAD.

This free open source tool and its unusual approach to create objects by writing program code suits perfect to my needs.

Only 3 hours later I had finished my first CAD model of a head prototype and started the 3d printer. (I plan to upload all the STL files to thingiverse.com to share them with other makers who want to built their own home robots)

The first prototype of the robot front head:

The following 4 improved prototypes:

An early prototype showing the complete head shape:

The final front part without raspberry pi...

...and with raspberry pi and the touchscreen monitor:


The next step will be the neck design and the motors for moving the head and the neck.

Continue reading: Part 2 - Neck design and movement

Ultimaker 2+ arrived

Seven years ago in 2009 I started my first experiences with 3d printing.

It took 2 weeks to assemble my first 3d printer – a rapman from UK. It had no heated built plate and the software needed lot of tuning and testing.

The rapman in 2009:

Then in 2011 I got the makerbot thing-o-matic. It had a heated, automated build platform and only took 2 days to assemble. The software still needed time to tune and to find out the best setting.

All this time I never managed to get PLA printing well – only ABS worked fine for me.

The makerbot in 2011:

Yesterday – 5 years after the makerbot – my ultimaker 3d printer arrived.
In my opinion there are worlds between these two last devices.
The ultimaker looks like from the future with its white led lighted housing, while the makerbot looks like from the past with his wooden case.
The ultimaker prints a lot of finer and more silent than my old makerbot.
No (or only a little bit) software tuning is needed– it is nearly plug and print.
It is very impressive for me to see, how big the improvements of these 5 years are.

Here are some impressions:

Pedestrian pathfinding part 2: Collision detection

I spent much time during the last weeks in programming the pedestrian pathfinding. After investing much work into the buggy implementation of evasion pathfinding algorithm and many hours of debugging now it seems to work.

Instead of the vehicle implementation (using Dijkstra pathfinding) for the pedestrian I use a jumpoint-pathfinding and a grid map. 

To prevent pedestrians from colliding with aother pedestrian, they mark their map pos as blocked (drawn red in the screenshot).



To synchronize between the vehicles and the pedestrians the vehicles project their actual position onto the pedestrian map (drawn black in the the screenshot). So no pedestrian can enter a field, a vehicle is driving across. 

Only for exceptional cases (when the blocking of the map has not prevented a collision) there is a front collider attached to each pedestrian.



Pathfinding seems to work fine now. So I can now go on with a little more exciting part of game development including graphic stuff and game mechanics.

Kinect for Windows V2: USB 3.0 ist nicht USB 3.0 :-/

Die für die Entwicklung eines Piratenspiel-"Ganzkörper"-Jump´n´Run vorgesehene Kinect für Windows V2 ist nun eingetroffen.

Im Vergleich zur ersten Version der Kinect scheint das Gerät noch etwas schwerer geworden zu sein und sondert (ebenso wie der Vorgänger) reichlich Wärme ab. Wahrscheinlich zusammen mit dem damit verbundenen Stromverbrauch ist dies auch der Grund, warum (leider) weiterhin ein externes Netzteil nötig ist.

Dafür ist das ganze etwas stylischer, da die Infrarot-Komponenten offenbar hinter die für das menschliche Auge undurchsichtige Frontblende versteckt wurde. Dadurch sieht man bei der neuen Kinect nur eine statt drei Objektive.

Eine dicke Enttäuschung dann aber gleich zu Anfang:
Die Kinect arbeitet nicht mit meinem PC zusammen. Nach längerer Recherche im Internet stellte sich dann heraus: Es wird USB 3.0 benötigt. Ok, das wusste ich und mein Desktop PC hat auch entsprechende Ports.

ABER: Die Kinect arbeitet nicht mit jedem USB 3.0 Controller zusammen. Genauer gesagt scheint Sie nur mit den Chipsätzen exakt zweier Hersteller zu funktionieren.
In meinem PC war aber "natürlich" eine andere USB 3.0 Karte verbaut. Da frage ich mich doch ernsthaft, wie Microsoft es hin bekommen kann, ein Gerät auf den Markt zu bringen, welches offiziell mit einem Standard zusammenarbeitet, dann praktisch aber doch nicht...
Wenn es noch die Vorabversion wäre: ok. Aber hier handelt es sich um die normale Verkaufsversion :-/

Nach dem Kauf und Einbau einer weiteren USB 3.0 PCI Karte klappt das ganze dann nun einigermaßen-  die gelieferten Framerate sind aber relativ instabil und berechen teilweise auf 5 FPS zusammen, obwohl der PC sich laut Taskmanager langweilt.

Oculus Rift DK2 - unboxing und erster Eindruck

Glückliche Überraschung heute: Die 2. Version des Oculus Rift Development Kits war in der Post.

Beim Auspacken, dann gleich eine kleine Enttäuschung: Statt eines schönen Kunststoffkoffers - in welchem die erste Version geliefert wurde - kommt das DK2 in einem Papp-Karton.

Im Karton selbst sieht es dann wieder der ersten Entwicklerversion ähnlich:

Die Linsen wirken etwas größer als beim DK2, dafür ist aber nur eine alternative Sehstärke dabei. Beim DK1 waren es noch zwei.

Neu ist in dieser Version die Erfassung von Kopfbewegungen im Raum (die erste Version konnte nur Drehbewegungen erkennen). Die eine Hälfte meines Kinect-Oculus-Projektes vom letzten Jahr ist damit nun abgelöst worden.

Damit das gelingt, verwendet die Brille nun eine zusätzliche Infrarot-Kamera. In der Rift-Brille sind IR-LEDs versteckt eingebaut, welche von der Kamera erkannt werden. Dadurch kann die Position im Raum ermittelt werden.

Entfallen ist das Adapter-Kästchen, so dass die Kabel jetzt ohne Ballast direkt an den PC angeschlossen werden können.

Den wichtigsten Eindruck kann ich hier im Blog aber natürlich nicht zeigen: Ist das DK2 besser als die vorherige Oculus Rift?

Definitiv! Die Auflösung ist zunächst einmal deutlich besser. Dazu kommt, dass die Kopfbewegungen den Eindruck noch einmal wesentlich realistischer machen. Oculus liefert eine Demo-Szene mit, in welcher man vor einem Schreibtisch sitzt. Durch die Bewegungen kann man die Objekte auf dem Schreibtisch wirklich aus der Nähe und von der Seite betrachten.

Wenn man den Eindruck der ersten Brille schon schlecht beschreiben konnte, sondern besser zeigen musste, toppt die zweite Version die Erfahrung noch einmal deutlich.