tiny little gizmos

eCommerce Camp Jena 2018

Am 23. und 24. März fand in Jena das mittlerweile sechste eCommerce Camp statt. Auch bei meinem dritten Besuch, verlief die Veranstaltung im gewohnten Rahmen: Am Vorabend trafen sich viele der Teilnehmer nach der Anreise zum Plausch bei Bier und deftigem Thüringischen Essen in der Gaststätte zur Nöll in der Altstadt. Die eigentliche Veranstaltung fand am Freitag und Samstag Vormittag in der Ernst-Abbe Hochschule in Form einer Unconferenz statt.

Jena - Zeiss neben der Ernst Abbe Hochschule

Jena – Zeiss neben der Ernst Abbe Hochschule

Nach einem gemeinsamen Frühstück bildete sich die Schlange mit den Teilnehmern, die einen Vortrag oder einen Workshop vorbereitet hatten. Einer nach dem anderen trat auf die Bühne und stellte dem Saal sein Thema vor.

Die Einreichungen wurden thematisch sortiert und auf die Slots verteilt. Am Ende stand ein voller und interessanter Vortragsplan.

Unconference Programm

Unconference Programm

„Da muss der alte Mann jetzt mal selbst ran“

Im Vorjahr hatte mich der Mitveranstalter gefragt, ob ich nicht auch mal ein Thema vorbereiten möchte. In diesem Jahr nahm ich die Arbeit auf mich und habe einen Vortrag vorbereitet. Er ist betitelt „No KISS – we’re doing it wrong“ und handelt von Trends in der Softwareentwicklung, die ich für problematisch oder gar falsch halte.

Die Kernthese lautet, dass sich viele Trends etablieren, die Software sehr aufblähen, langsam und angreifbar machen und entgegen der Intention auch nicht für bessere Wartbarkeit und Wiederverwendbarkeit sorgen. Als Beispiele nannte ich u.a. fette Frameworks, unbedachter Einsatz von Libraries, Annotations, ORM, Metasprachen und zu viele Basistechnologien im Setup.

Da ich noch nie bei solch einer Veranstaltung vorne stand, war ich auch etwas nervös. Werde ich einen Hänger haben? Interessiert das Thema überhaupt jemanden? Da mein Vortrag etwas gegen den Entwickler-Mainstream gebürstet war war ich auch gespannt, ob meine Thesen in der Luft zerrissen würden. Zudem hatte ich kaum Zeit, mich seelisch vorzubereiten, weil ich gleich in den ersten Slot nach der Einführungsveranstaltung dran war.

Es stellte sich heraus, das meine Bedenken unbegründet waren. Mein Vortrag war flüssig, es waren ca. 20 Zuhörer im Raum, was für diese Veranstaltung gar nicht mal so wenig ist. Zum Ende des Vortrags kam es nochzu einer kurzen Diskussion über den einen oder anderen Punkt, aber alles in allem erntete ich viel Zuspruch, wie sich auch noch in einigen Gesprächen im Tagesverlauf zeigte.

Ein Teilnehmer meinte, dass er ähnliches in letzter Zeit häufiger gehört habe und die Kritik meist von älteren Entwicklern kämen und ob das Zufall sei. Meiner Meinung nach ist das kein Zufall, sondern es hängt damit zusammen, dass wir älteren Entwickler früher an Maschinen entwickelt habe, die sehr beschränke Ressourcen hatten. Der Rechner war immer zu langsam, hatte stets zu wenig Speicher und die Übertragungsgeschwindigkeit war immer langsam. Daher sind wir es gewohnt, auf Ressourcenverbrauch zu achten. Heutzutage spürt man zunächst keine Ressourcenknappheit. Daher ist es sehr einfach, eine Anwendung aus vorgefertigten Elementen „schnell zusammenzustöpseln“. Dass man ein Problem hat, merkt man erst, wenn unerwartet viel Traffic auf den Server einprasselt, aber dann liegt das Kind bereits im Brunnen.

Gutes Programm, spannende Gespräche

Das gute daran, den ersten Slot zu bekommen ist, dass man sich danach entspannt auf die Vorträge der anderen konzentrieren kann. Für mich aktuell einer der wertvollsten Vorträge war „MySQL Profiling“, den Andreas Ziethen von Scale hielt. Sein Vortrag setzte genau dort an, wo mein Wissen aufhörte. Nach einer Einführung in das Tool zur Auswertung von Datenbank Logfiles wurden einige Auswertungen von echten, aktuellen Problemfällen zusammen mit den Hörern vorgenommen – sozusagen Gruppendebugging.

Kontrovers diskutiert wurden die Vorschläge für eine neue Shoparchitektur, die Marcus Franke und Richard Burkhardt in der Session „E-Commerce Performance neu gedacht! Proof of Concept: Schnelle Webshops ohne Caching“. Der Wunsch, das Caching aus den Shops zu entfernen ist groß und Vorschläge dazu sehr willkommen, wie sich an recht vielen Hörern im Saal zeigte. Der präsentierte Prototyp, der eine Kategorieseite aus einem Datensatz von einer halben Million Artikeln in 0.4 Sekunden zeigte, basierte auf dem Konzept eines Application Servers, wie man ihn aus der Java Welt kennt. Aus dem Publikum kamen jedoch recht gewichtige Gegenargumente: Zweifel, ob PHP für lang laufende Prozesse stabil genug ist, hoher Ressourcenverbrauch und Fragen wie die Objektdaten  im Speicher aktuell gehalten werden. Nach meiner Ansicht das stichhaltigste Argument war, dass der Showcase deshalb so schnell sei, weil alles, was einen echten Shop ausbremst (Framework, ungenutzte Features, Konfigurationsmöglichkeiten,…) nicht implementiert ist. Wenn man dasselbe mit plain PHP baut, kommt man vermutlich auf ähnlich schnelle Zeiten.
Zwar ist es nicht schön, wenn einem die eigene Arbeit so zerpflückt wird, aber die Argumente waren plausibel und der Ton kollegial. Ich finde es auf jeden Fall sehr gut, dass die beiden sich nicht nur Gedanken gemacht haben, sondern auch noch viel Zeit in einen Showcase investiert und das Ergebnis zur Debatte gestellt haben.

 

Ein Herz für Nerds

Ein Herz für Nerds

Das abendliche Unterhaltungsprogramm im Paradies Cafe habe ich in diesem Jahr nicht so ausgekostet, wie 2017. Ich war nicht so richtig in Feierlaune und mir schienen auch die anderen Konferenzteilnehmer in diesem Jahre etwas zurückhaltender. Das war aber nicht unbedingt von Nachteil, weil es der Konzentration am Samstag Vormittag zu Gute kam.

Simon Pearce von SysEleven zeigte, wie man mit Hilfe von Kubernetes und einigen einfachen Konfigurationsdateien in wenigen Minuten ein MySQL Datenbankcluster mit einem Master und drei Slave Nodes bauen kann. Bereits am Vortag hatte er demonstriert, wie ein Setup aus NGINX Webservers so aufgesetzt werden kann, dass bei Bedarf automatisch weitere Serverinstanzen gestartet und bei abnehmender Last wieder gestoppt werden können.

Kurz vor bevor ich zurück nach Berlin fahren wollte, bekam ich in einem sehr interessanten Gespräch nebenbei eine Vorführung eines begeisterten Shopbetreibers in Echtzeitprofiling seines Shops mit Tideways und eine Diskussion über den Umgang mit der Datenschutzgrundverordnung. Zu meiner Verblüffung erfuhr ich von einem mir bekannten Shop, der mittlerweile völlig auf die Speicherung von personenbezogenen Daten verzichtet. Das Shopsystem selber ist „clean“, so wie ich es von Bankenanwendungen kenne. Ich bin gespannt, ob sich so etwas rumspricht und durchsetzt.

Fazit

Dieses spontane Gespräch am Rand zeigt auf, was diese Veranstaltung in meinen Augen so wertvoll macht: Der spontane, offene und ehrliche Austausch über Probleme und Lösungen. Ich hoffe sehr, dass diese Veranstaltung auch in den nächsten Jahren fortgeführt wird.

 

 

„Why I still use DOS“ und warum ich das sehr gut verstehe

Gerade macht die Aussage von George RR Martin, dem Autor von Game of Thrones, die Runde, dass er auf einem völlig veralteten Rechner schreibt (siehe BBC Artikel). Er nutzt Wordstar 4.0 auf einem Rechner unter MS-DOS.

Kopfschütteln und Lachen

Bei vielen wird er damit auf Missverständnis stoßen. In dem unten gezeigten Interview schütten sich die Zuhörer aus, vor Lachen. Er selber bezeichnet sich als Dinosaurier und bedient damit (auch optisch) das Klischee von dem alten Mann, der irgendwie stehen geblieben ist und den alten Zeiten nachtrauert.

 

Nicken und Zustimmung

Der Eindruck täuscht. Ich halte Martin nicht für rückständig, sondern für zielorientiert. Er fokussiert sich auf das Ziel, eine Geschichte zu schreiben. Dazu benutzt er das Werkzeug, das ihn am besten dabei unterstützt. Martin ist der Meinung, dass dieses alte System wesentlich besser dafür geeignet ist, als moderne Software auf neuen Rechnern. Als Begründung führt er vor allem die automatische Rechtschreibkorrektur an, die regelmässig seine Texte zerschreddert. Das führte im Internet zu wohlmeinenden Kommentaren, wie bei Office die Rechtschreibkorrektur auszuschalten ist. Diese Kommentare gehen aber eigentlich am Problem vorbei, denn Martin hat recht. Er ist in diesem Fall der Experte. Wer hier eindeutig nicht Experte ist:

  • Börsenanalysten, die Softwarefirmen bewerten
  • Marketing Spezialisten von Software Firmen
  • Produktmanager von Software Firmen
  • User Interface Designer bei Software

Die o.g. Personengruppen haben zum Ziel, ständig neuen Umsatz zu erzeugen, indem sie ständig neue Software auf dem Markt bringen.

Martin hingegen will nur ein möglichst effizientes Werkzeug zum Schreiben. Er sagt „I like Wordstar 4.0. It’s a word processor that does everything I need. And it does nothing else“ und bringt damit eine zunehmend problematische Entwicklung auf den Punkt:

Die digitalen Werkzeuge werden schlechter

Die Autokorrektur ist nur ein Beispiel unter vielen: Ständige Ablenkung durch aufpoppende Nachrichten, Update Meldungen, E-Mails, Twitter Nachrichten und so weiter. Permanente Nerverei durch Antiviren Software, Firewalls, Zwangsupdates, Bedienoberflächen, die alle paar Monate geändert werden, Daten die man nicht mehr lokal speichern kann, gültige URLs, die der Browser nicht akzeptiert, weil sie nicht mit www anfangen oder mit .com aufhören.

Zwang, Besserwisserei, Bevormundung, Überfrachtung, wohin man auch sieht. Und weil Computer mittlerweile in so ungefähr alles eingebaut werden, gibt es auch keine reifen Produkte mehr. Immer muss irgendwas upgedatet und ausgebessert und nachgerüstet werden. Junge Leute von heute wissen vermutlich gar nicht, dass man ein Produkt früher fertig entwickelt hat, bevor man es auf den Markt brachte.

In der Vergangenheit, haben uns Computer viel Nützliches gebracht: Bessere Produkte durch präzise Fertigung, Saubere Motoren und Heizungen durch bessere Steuerung, demokratisierung der Medienproduktion und so weiter.

Ich werde aber das Gefühl nicht los, dass sich die Entwicklung der Nützlichkeit vor einiger Zeit den Höhepunkt erreicht hat und nun eher wieder sinkt.

Gibt es neben Peak Oil vielleicht auch Peak Digital – den Zeitpunkt, ab dem es mit der Nutzung digitaler Güter wieder abwärts geht?

Ein kleiner Vortrag

Nachdem ich mein kleines Spiel Colorflood für den Commodore 64 fertiggestellt hatte, lud mich Dr. Stefan Höltgen ein, darüber einen Vortrag an der Humboldt Universität zu halten. Gestern Abend war es dann soweit. Im Signallabor des Fachbereichs Medienwissenschaften sprach ich vor kleiner, aber interessierter Runde über die Entstehung des Spiels.

Ollmetzer erzählt...

Ollmetzer erzählt...

Ich sprach von der Motivation, weshalb ich mich heuzutage (wieder) mit alter, einfacher Technik auseinandersetze, über Ziele und die Herangehensweise, sowie natürlich über die technische Umsetzung. Im Anschluss wurden dann noch einige Runden auf den vorbereiteten C64 und C128 gespielt. Den Abend ließen wir dann gemeinsam mit Fachgeprächen bei einem gemütlichen Umtrunk in einem nahegelegenen Restaurant ausklingen.

5ct. Szene heroes…

Vor ein paar Tagen habe ich mein Spiel colorflood für den Commodore64 veröffentlicht. Ein kleines, einfaches Casual Game. Ein paar Leute haben es auch schon gespielt und sich wohlwollend geäußert.

Eben finde ich es auf CSDB (Commodore Szene Database) – und zwar als „Crack“. Nicht dass ich etwas dagegen habe, dass mein Spiel dort zu finden ist – aber als Crack???
Cracks sind eigentlich Spiele, deren Kopierschutz geknackt wurden und dann mit einem entsprechenden Intro versehen wurden.

Mein Spiel hat keinen Kopierschutz. Man darf es kopieren. Das Programm liegt hier – bitte sehr. Ich habe sogar den Quellcode veröffentlicht, und zwar hier. Daraus einen „Crack“ zu machen ist, wie alte Omas vor den Bus schubsen: Sehr einfach, sehr blöde und spricht nicht gerade für einen guten Charakter.

Mannmannmann, das ist ja wie damals, als sich pubertierende 14 Jährige in der „Szene“ wichtig gemacht haben…

Colorflood für Commodore 64 – fertig

Vor zwei Wochen schrieb ich über das kleine Spielchen, dass ich für den Commodore 64 programmiere. Die Idee hatte ich bereits letzten Sommer. Das ganze alte Know-How über 6502 Assembler und die Systemarchitektur des C64 rauszukramen und sich wieder  daran zu gewöhnen, Daten direkt durch Speicher, Prozessor und Videochip zu schieben hat etwas gedauert. Nun ging es dann aber doch erstaunlich schnell. Das Spiel ist fertig (Download: siehe unten).

Stumm ist dumm

Die Spielmechanik hatte ich vor zehn Tagen fertig und nun wollte ich noch eine kleine Titelmelodie einbauen. Komponiert habe ich auf meiner Audioworkstation mit dem genialen Reason von Propellerheads. Um die Noten auf den C64 zu übertragen und abzuspielen habe ich den Soundmonitor von Chris Hülsbeck verwendet, der 1986 in der 64er erschienen ist. Die Software gilt als der erste Musik Tracker. Die Abspielroutine und die Daten verbrauchen leider sehr viel Speicherplatz und Prozessorzeit, aber da das Programm sehr klein ist und die Melodie nur im Titel und nicht während des Spiels läuft, macht das nichts.

So siehts aus

Das Spielprinzip ist absichtlich simpel, die Grafik und die Melodie ebenfalls. Spaß macht es (mir) trotzdem.

Colorflood - Titelscreen

Colorflood - Titelscreen

Farbwechsel von Braun zu Violett - Die Welle rauscht vorwärts

Farbwechsel von Braun zu Violett - Die Welle rauscht vorwärts

„Auch mal spielen?“

Alle Liebehaber des C64 sind herzlich eingeladen, Colorflood herunterzuladen und in ihre Spielsammlung aufzunehmen. Über Feedback freue ich mich natürlich auch.

Das Spiel ist Open Source; die Quelldateien und das fertige Programm (colorflood.prg) liegen auf GitHub:

https://github.com/dollmetzer/colorflood

Das fertige Spiel in einer D64 Datei (Diskettenimage) gibt es hier: colorflood.d64

Viel Spass!

Farbflut auf dem Commodore 64

Seit letztem Jahr treibe ich mich in Berlin regelmäßig auf diversen Veranstaltungen mit dem Thema Retrocomputing herum. Ich habe viele interessante und teils verblüffende Dinge gesehen, die man mit den alten 8-Bit Maschinchen machen kann. Ich fand heraus, dass es noch immer eine lebendige Szene für meinen Lieblingscomputer Commodore 64 gibt und noch immer neue Software für das über 30 Jahre alte Schätzchen erscheint.

Ich will auch mal wieder…

Im letzten Sommer – nachdem ich den Vortrag von Berthold Fritz über die Programmierung eines Spiels für die 8 Bit Atari Heimcomputer gehört hatte – nahm ich mir vor, auch mal wieder ein kleines Spielchen zu programmieren. Und zwar so richtig maschinennah in Assembler – wie man das damals meist getan hat.

Es muss nichts aufregend, originelles, großes sein. Irgendwas nettes kleines, was man gerne mal für 10 Minuten spielt. Berthold Fritz hatte sich an Boulderdash orientiert, aber von solchen Spielen gibt es gefühlt hunderte für den C64. Was also tun?

Als ich meinen Raspberry Pi das erste mal eingeschaltet hatte, stolperte ich über ein kleines, in Python programmierte Spiel, bei dem man ein buntes Spielfeld durch Farbwechsel einfarbig bekommen soll. Total simpel und einfach – aber ich saß wie gebannt davor und habe das tatsächlich elend lange gespielt. Das Prinzip macht Spaß und man benötigt weder bombastische Grafik noch umwerfenden Sound. Bingo – so machen wir es!

Proof of concept: colorflood in Basic

Proof of concept: colorflood in Basic

Den Algorithmus für den Farbwechsel habe ich zunächst in Basic programmiert, um zu überprüfen ob er wirklich so einfach ist, wie ich gedacht habe. Das Ergebnis war lauffähig, aber wie zu erwarten war auch unglaublich langsam. Immerhin – der Proof of Concept war erbracht. Den Programmcode habe ich bei Github hinterlegt.

Das Projekt colorflood ist mittlerweile in einem Stadium, in dem ich es auch mal zeigen kann. Es gibt:

  • Eine einfache Startseite. Los geht es mit Druck auf den Feuerknopf von Joystick 2.
  • Das Spielfeld wird aufgebaut
  • Die Farben werden zufällig gesetzt
  • Mit dem Joystick kann man die nächste Farbe auswählen und per „Feuer“ setzen.
  • Der Farbwechsel wird animiert angezeigt
  • Die Anzahl der Farbwechsel wird gezählt (ist aber noch nicht limitiert)
  • Es gibt einen Countdown (der aber noch nicht bei 000 den Level beendet)
  • Wenn das komplette Spielfeld eingefärbt ist, wird der Level beendet (und damit zur Zeit auch das Spiel)

Als nächstes werde ich die verschiedenen Beendigungen eines Levels und die Erhöhung des Schwierigkeitsgrades im nächsten Level programmieren. Danach Sound und zum Abschluss hoffentlich noch eine Titelmelodie.
Die vollständigen Projektsourcen sind hier zu finden:

https://github.com/dollmetzer/colorflood

Wenn das Spiel fertig ist, werde ich es auch als fertig übersetztes Programm zur Verfügung stellen.

Bewegungserkennung per Webcam

Für ein kleines Projekt stand gerade vor der Aufgabe, Standbilder per Webcam aufzunehmen und zu speichern – aber nur, wenn sich etwas vor der Linse bewegt.
Das klingt zunächst reichlich kompliziert, aber mit den richtigen Werkzeugen ist es tatsächlich verblüffend einfach. Die Werkzeuge der Wahl sind:

  • Python – Eine populäre Skriptsprache
  • OpenCV – Eine Funktionsbibliothek für Bild-, Videobearbeitung, Mustererkennung u.ä.

Den rechten Weg wies mir Matthias Stein mit seinem Artikel „Motion detection using a webcam, Python, OpenCV and Differential Images„. Die Bewegungserkennung funktioniert so, dass drei kurz nacheinender aufgenommene Bilder übereinandergelegt werden und daraus ein Differenzbild errechnet wird. Dort wo sich nichts verändert hat, ist das Differenzbild schwarz. Stellen, die sich verändert haben, werden weiß. Das führt zu recht eigenwilligen, geisterhaften Bildern, wie man in dem Beispielvideo auf Youtube sehen kann.

Die Lösung

Die Methode musste ich nun nur noch etwas ergänzen. Aus dem Differenzbild errechnet die OpenCV Methode countNonZero die Anzahl, der weißen Pixel. Falls dieser Wert oberhalb eines gesetzten Schwellwertes (sinnvollen Wert ausprobieren) liegt, soll das Bild gespeichert werden. Jetzt muss man nur noch dafür sorgen, dass das Ursprungsbild in Farbe vorliegt und nur zur Differenzberechnung in Schwarz/Weiss gewandelt wird. Et voilá…

Für die interessierten ist hier der Code:

#! /usr/bin/python

import time
import cv2

def diffImg(t0, t1, t2):
    d1 = cv2.absdiff(t2, t1)
    d2 = cv2.absdiff(t1, t0)
    return cv2.bitwise_and(d1, d2)

print "Start Capturing"
cam = cv2.VideoCapture(0)

# Threshold for minimum movement
threshold = 130000
targetdir = './'
winName = "MovementIndicator"
cv2.namedWindow(winName, cv2.CV_WINDOW_AUTOSIZE)

# Read three images first:
colorimg = cam.read()[1]
t_minus = cv2.cvtColor(colorimg, cv2.COLOR_RGB2GRAY)
t = cv2.cvtColor(colorimg, cv2.COLOR_RGB2GRAY)
t_plus = cv2.cvtColor(colorimg, cv2.COLOR_RGB2GRAY)

start = time.time()
while True:
    dimg=diffImg(t_minus, t, t_plus)
    cv2.imshow( winName, dimg )

    # save picture, when movement above threshold
    print cv2.countNonZero(dimg)
    if cv2.countNonZero(dimg) > threshold:
        timestamp = round(time.time() - start)
        filename = targetdir + str(timestamp) + ".jpg"
        cv2.imwrite(filename, colorimg)

    # Read next image
    colorimg = cam.read()[1]
    t_minus = t
    t = t_plus
    t_plus = cv2.cvtColor(colorimg, cv2.COLOR_RGB2GRAY)

Firefox: URL vervollständigen ausschalten

Wenn ich etwas hasse, dann sind es Computer, die schlauer als der Nutzer sein wollen. Darunter fällt das unsägliche automatische Ergänzen der URL um www und .com, das Firefox ungefragt vornimmt. Die Grundannahme, dass eine Domain immer mit www. anfängt und mit .com aufhört ist ja totaler Quatsch. Das stimmt schon bei „richtigen“ Domains häufig nicht, bei der Entwicklung aber schonmal gar nicht. Ich benutze gerne einfache URLs, wie zum Beispiel http://shop/.

In den normalen Einstellungen von Firefox steht dazu nichts. Wie wird man den Quatsch also los?

Man gibt in der Adresszeile about:config ein und bestätigt, dass man vorsichtig ist. Dann sucht man nach dem Schlüssel keyword.enabled und ändert den Wert von true auf false.

Zur Sicherheit löscht man auch noch die Werte der Schlüssel browser.fixup.alternate.prefix und browser.fixup.alternate.suffix.

Happy browsing!

The next big (little) things?

In den letzten 3-4 Jahren las man immer mal wieder etwas über 3D Druck. In technischen Veröffentlichungen ging es meist um die Technik an sich und in den normalen Medien wurde – wie leider mittlerweile üblich – wieder nur stupide Stimmungsmache und Panik verbreitet. Beide Arten der Veröffentlichungen finde ich mindestens sinnlos, wenn nicht sogar eher schädlich, weil sie eine sachliche Diskussion verhindern.

Einerseits, werden keine möglichen positiven Anwendungen, wie z.B. die Herstellung selten gebrauchter Ersatzteile gezeigt. Die Suche nach Chancen findet mal wieder nicht statt.

Andererseits werden aber die wirklich relevanten Herausforderungen, wie die möglichen Umwälzungen auf Produktion und Beschäftigung ebenfalls nicht thematisiert. Stattdessen werden ausschliesslich sensationsheischende Schlagzeilen wie „Waffen aus dem 3D Drucker“ thematisiert. Mein Gott! Als ob man Waffen nicht aus allem möglichen Zeug herstellen kann, wenn man es denn darauf anlegt. 3D Drucker sind da schon vom Metrial her eher nicht geeignet, wie ein Praxistest gezeigt hat, den die Zeitschrift C’t in Zusammenarbeit mit einem Büchsenmacher durchführte.

Wo liegen denn nun mögliche Einsatzzwecke?

Der eigentliche Witz beim 3D Druck ist, dass das Open Source Prinzip nach der Software nun auch in der Harware angekommen ist. Das wiederum gibt einem weiteren, interessanten Zukunftsthema weiteren Schwung: Der Robotik.

Robotik an sich ist zwar keinesfalls ein neues Gebiet, aber die Entwicklung erfolgte bisher Top-Down. Konzerne mit millionenschweren Forschungsbudgets und Universitäten haben sich hier hervorgetan und auch bereits beachtliches geleistet. Der wirkliche Durchbruch in der Alltagswelt der Menschen wird aber vermutlich eher durch eine Bewegung „von unten“ vorangetrieben werden. Genauso, wie erst die zunächst belächelten Microcomputerbasteleien einiger Freaks in den 70er Jahren den Computer als Alltagsgerät für die Massen ermöglichte.

3D Druck als Bottom-Up Treiber in der Robotik

3D Drucker selbst sind ja bereits eine spezielle Art von Robotern. Bei den meisten Modellen sind auch bereits viele Teile selbst per 3D Druck hergestellt, die Steuerelektronik basiert meist auf offenen Hardwarespezifikationen, wie dem Arduino und die Software von der Konstruktion bis zum Hardwaretreiber sind ebenfalls meist Open Source.

Dieses bei dieser mittlerweile bewährten Art der offenen Entwicklung durch eine motivierte Gruppe enstandene Know-How, wird nun zunehmend auf andere Bereiche der Mechatronik transferiert. Zwei wie ich finde interessante Projekte sind Shellmo und Poppy.

Während sich das insektenähnliche Shellmo eher als ein interessantes technisches Spielzeug darstellt, merkt man dem humanoiden Poppy Project sein ambitioniertes Ziel deutlich an. Viel Spass beim Ansehen.

 

 

 

Nächste Seite »