Just playing around with the ultimaker...

Now I have the Ultimaker for over a year and have only the 0.4 mm nozzle used so far.

Time to try out the 0.23 mm nozzle ...

First tries with Nikola Tesla, Mario and the 0.23 mm nozzle.

Some more Nikola Tesla in 0.23mm...

... and with the 0.4mm nozzle (left: raw PLA, right: painted)

A Bitcoin and a Pirates of the Caribbean Medallion - both painted and printed using the 0.23mm nozzle.

I am Groot! Painted and using the 0.4mm nozzle.


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.