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)
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!
rm -rf * solves most problems. sudo rm -rf * solves them all
(Kommentar bei raspberrypi.org)
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.
Dirk Ollmetzer | Donnerstag, 12 Dezember 2013 |
DevelopmentBei Scrum-Daily:
„Häng doch das blöde Ticket endlich auf das Bashboard…“
Denselben Effekt hat man aber auch mit Subversion oder ähnlichen Systemen.
Wieder mal ein Treffer von XKCD. Bin eben vor Lachen fast vom Stuhl gerollt. Schade, dass das nur Entwickler richtig verstehen…
Am letzten Dienstagabend fand nach längerer Pause wieder einmal das Treffen der Oxid Usergroup Berlin statt.
Die Veranstaltung fand ab 18:00 in den Räumen von SysEleven in Kreuzberg statt. Nach einer kurzen Vorstellungsrunde ging es gleich sehr technisch zur Sache. Felix Gilcher von Asquera startete mit einem Vortrag über den Suchindex Elasticsearch. Er begann mit einem Überblick über die Architektur (Clusterserver, Shards, Indizes, Documents…) und die grundlegende Benutzung per JSON Calls mit Indexern, Analyzern und Filtern.
eCommerce im Umspannwerk
Josha Krug von der Agentur Marmalade ergänzte das Thema mit den Erkenntnissen, die beim Einsatz von Elasticsearch bei einem Online Buchhändler gewonnen wurden. Es wird dort nicht nur für die Suche, sondern auch für das Ausspielen der Kategorieseiten genutzt.
Im Verlauf der Diskussion wurde als weiterer möglicher Einsatzzweck System- und Eventlogging besprochen. Dafür gibt es mit Kibana und Logstash auch bereits gute Frontends.
Es folgte ein etwas weniger technischer Teil. Ein Shopbetreiber fragte in die Runde nach Erfahrungen bei der Auswahl geeigneter ERP Systeme. Es wurde auf die hohe Anzahl an Spezialanbietern (z.B. jewils unterschiedliche Systeme für Tischler und Zimmerleute) hingewiesen und auch das Thema Cloud ERP mit Vorteilen beim Dropshipping wurde angerissen.
Im Abschluss wurde es wiederum sehr technisch. Daniel Niedergesäß von SysEleven führte anhand von OXID 4.7 CE vor, welch großer Performancegewinn sich durch den Einsatz von Facebooks HipHop Virtual Machine erzielen lässt. Mit HipHop compiliert man aus einer PHP Applikation samt PHP selbst und den notwendigen Libs eine Binärcode Anwendung.
Da HipHop aber noch nicht den vollständigen Sprachumfang von PHP unterstützt und an einigen wichtigen Stellen, wie der Sessionverwaltung von Standardverhalten abweicht, sind leider einige recht tiefe Eingriffe in den Core von Oxid, der vollständige Verzicht auf verschlüsselten Code und recht speziell eingerichtete Server nötig, um den Shop zum Laufen zu bekommen.
Für den Produktiveinsatz ist solch ein System daher leider noch nicht geeignet, aber es zeigt auf, welches Potential hier vorhanden ist.
Nach dem offiziellen Ende der Veranstaltung um 21:00 ließen einige Teilnehmer den Abend noch gemeinsam in einer Gaststätte ausklingen.
Auch in dieser Woche gab es wieder einen hervorragenden Vortrag aus der Reihe Shift-Restore-Escape an der Humboldt Universität. Nachdem die bisherigen technischen Vorträge stets davon handelten, neue Software auf bekannter alter Hardware zum Laufen zu bringen, ging es diesmal ans Eingemachte. Das Thema des Abends lautete
Mit Lötkolben, Wire-Wrap-Pistole und Assembler – Z80 Selbstbaurechner
Prof. Dr. Bernd Ulmann – Spitzname „Vaxman“ – ist eigentlich für den Umgang mit richtig grossen Geräten bekannt. Er sammelt alte VAX Rechner von Digital Equipment. Dennoch hatte er Lust „schnell mal eben“ einen kleinen Z80 Rechner selbst zu bauen. Gesagt, getan. Das Projekt hat er auf seiner Homepage unter http://www.vaxman.de/projects/tiny_z80/ ausführlich dokumentiert, so dass ich mir hier Details spare.
Die naheliegende Frage „Warum macht man sowas?“ beantwortete er gleich am Anfang augenzwinkernd mit „wegen einer kleinen Midlife-Crisis“ und weil man an solch einfachen Systemen den heutigen Studenten die Grundfunktion von Rechnern gut erklären kann.
Die Idee - Handskizze
Das Ergebnis der Arbeit ist ein Einplatinenrechner, der per serieller Schnittstelle an andere Rechner angeschlossen wird. Er ist mit einem Mini-Betriebssystem, einem Monitorprogramm, einem Forth-Interpreter und experimentiell mit einem kleinen Basic Interpreter ausgestattet. Die weitaus meiste Arbeit steckt in dem Massenspeicher in Form eines CF-Karten Laufwerkes.
Hardware Revision 1
Mitten während der Entwicklung entdeckte Ulmann, dass mit dem N8VEM bereits ein vergleichbares Projekt existierte. Er hatte in der Veranstaltung sowohl den N8VEM, als auch die zweite Revision seines eigenen Rechners dabei, der mit einer deutlich kleineren Platine auskommt und mich ein wenig an den seeligen Sinclair ZX81 einnerte, der aus nur vier Chips bestand.
N8VEM
Hardware Revision 2
Die abschliessende Live Präsentation wurde mit einer Aufgabe durchgeführt, die in den 80er Jahren sehr populär war: Der Berechnung einer Mandelbrot-Menge. Einmal in Basic und einmal in Assembler. Ein- und Ausgabe erfolgten dabei in ASCII Code auf dem Terminalprogramm eines aktuellen Apple Laptops.
Live Demo
Gestern hatte ich wieder das Vergnügen einem wirklich tollen Vortrag aus der Reihe Shift – Restore – Escape an der Humboldt Universität in Berlin beizuwohnen. Das Thema des Vortrags von Norbert Kehrer war:
Emulation des Spieleklassikers Asteroids für Homecomputer
Asteroids ist einer der absoluten Spielhallenklassiker, den Atari im Jahre 1979 herausgebracht hat. Es handelt sich um einen Weltraumshooter, der neben seinerzeit sehr innovativen Steuerung vor allem durch die präzise grafische Darstellung brilliert. Im Gegensatz zu den seinerzeit üblichen Rastermonitoren mit bescheidenen Auflösungen um 129 x 240 Pixel, zeichnet dieser Monitor die Umrisse der Spielfiguren ähnlich wie ein Oszilloskop direkt nach. Statt Pixel sieht man gestochen scharfe Linien.
Das Spiel ist natürlich bereits zigfach auf allen denkbaren Plattformen – erst recht auf dem Atari 800 und dem Commodore64 – nachprogrammiert worden. Eine besonders gelungene Adaption ist das Spiel Minestorm, dass in die 1982 erschienene Spielkonsole Vectrex fest eingebaut war. Das Vectrex hatte ebenfalls einen Vektorbildschirm.
Minestorm auf Vectrex
Authentizität durch Originalsoftware
Was den Ansatz von Norbert Kehrer so interessant macht, ist, dass er sich weder um eine Nachprogrammierung, noch um eine Emulation handelt, sondern, dass er den originalen Programmcode des Automaten auf dem Atari 800 zum Laufen gebracht hat, was ein nahezu authentisches Spielgefühl beschert.
Asteroids auf Atari 800XL
Das ist nur deshalb möglich, weil der Spielautomat einen 6502 Prozessor verwendet – genau wie die Heimcomputer von Atari und Commodore. Die Taktgeschwindigkeit ist vergleichbar und der Programmcode hat die bescheidene Grösse von 6KB. Norbert Kehrer ging detailliert auf die Gemeinsamkeiten und Unterschiede der Plattformen ein.
Spezifikation von Asteroids
Der Hauptunterschied ist natürlich die vollkommen andersartige Bildgenerierung, denn die Heimcomputer wurden an Fernsehern betrieben und hatten daher eine Rasterdarstellung.
Raster und Vektorgrafik im Vergleich
Eine theoretische Möglichkeit wäre, die Vektoren auf den Rasterbildschirm umzurechnen und linienweise zu zeichnen, wie es z.B. M.A.M.E. macht. Leider sind die kleinen Heimcomputer dafür bei weitem zu langsam. Kehrer hat den Gameloop an der Stelle gepatcht, wo der Bildschirmrefresh aufgerufen wird und ersetzt die Vektorlogik durch eine Bilderzeugung per Softwaresprites. Doch selbst das gelingt nur, weil bestimmte Positionen der Objekte vorberechnet im vergleichsweise großzügigen Hauptspeicher der Computer abgelegt sind.
Asteriods - gefühlsecht
Das Ergebnis ist beeindruckend nahe am Original. Kein Wunder – es IST ja tatsächlich das Original.
Weitere originelle Projekte, wie die Emulation einer PDP8 auf dem Atari 800(!) finden sich auf der Homepage von Norbert Kehrer: Norbert’s Emulators.
Am Dienstag dieser Woche konnte ich wieder einen interessanten Vortrag aus der Reihe “Shift-Restore-Escape” an der Humboldt Universität hören. Das Thema:
Vom Wiedereinstig in die 8 Bit Welt – Die Programmierung eines Spiels für Atari Computer
Bevor der Vortrag begann, gab es zur Einstimmung ein paar astreine Chiptunes zu hören. Mein Eindruck war, dass sich der Sound gar nicht so sehr vom SID des Commodore 64 unterschied. In seiner Anmoderation erwähnte Stefan Höltgen dann zu meinem Erstaunen, dass die Musik vom TIA – also dem Grafikchip des Atari erzeugt wurde.
Berthold Fritz, Jahrgang ’69, begann seinen Vortrag damit, dass er die Motivation, heutzutage ein Spiel für den 30 Jahre alten Atari Homecomputer zu programmieren, darlegte. Den Entwicklungsprozess hat er in seinem Blog retrozock.com begleitend beschrieben.
Motivation
Fritz begann mit der Feststellung, dass er im Laufe der Zeit – von Heimcomputern über 16 Bit Rechner bis zu heutigen PCs immer mehr zum reinen Bediener und Konsumenten degradiert ist. Er war damit unzufrieden und wollte sich Wissen um die Funktion der Rechner erarbeiten. Die heutigen Rechner sind mit ihrer Komplexität, Mächtigkeit und zahlreichen API und Abstarktionslayern allerdings nicht gut geeignet. Daher erinnerte er sich an den Atari 800XL aus seiner Jugend.
Atari 800 XL von 1983
Die Frage was denn nun genau zu programmieren ist, war schnell beantwortet: Ein Spiel. Und zwar ein Spiel mit einfacher und bewährter Spielmechanik, bei der der Spass nicht unbedingt von umwerfender Grafik abhängt. Das Spiel Dirt, Rock, Diamonds and other Perils ist ein Nachbau des beliebten und of kopierten Boulder Dash. Der Entwicklungsprozess dauerte ca. 2 Jahre und ist noch nicht völlig abgeschlossen, da das Spiel zum Beispiel noch keine Musik hat.
Programmiersprache und Werkzeuge
Die Wahl der Programmiersprache wurde schnell entschieden. Die ersten Versuche, einen Spielbildschirm mit 800 Bytes in Basic aufzubauen führten zu dem erwarteten Ergebnis: Es ist viel zu langsam (ca. 3 Sekunden). Derselbe Algorithmus in Assembler schaffte das in weniger als einer 50stel Sekunde.
Die Frage, welche Werkzeuge zu verwenden sind, war bereits schwieriger. Soll es Crossdevelopment auf Macintosh mit einem Atari Emulator (Atari800MacX) sein oder soll direkt auf der Zielplattform entwickelt werden? Welcher Assembler mit welchem Vorgehen ist zu bevorzugen?
Fritz entschied sich dafür, direkt auf dem Atari zu entwickeln und zwar so, dass Sourcecode, Assembler und Objektcode gleichzeitig im Spiecher vorgehalten werden. Das ist komfortabel, schränkt jedoch die maximale Grösse des Programms stark ein. Das Spiel wurde letztlich ca. 5 KB gross.
Vom Werden und Wachsen
Die paar Befehle des 6502 Prozessors sind schnell gelernt, eine Memory Map hervorgeholt und los geht die Entwicklung. Die ersten Gehversuche sind noch völlig ohne Grafik und dienen der Überprüfung der Spielmechanik.
Spiel ohne Grafik
Nachdem hier die ersten Probleme gelöst wurden, kam handcodierte Grafik hinzu. Jetzt kann man schon das eigentliche Spiel erkennen. Die Farbigkeit hat mich sehr an DigDug erinnert.
Spiel mit erster Grafik
Manchmal ist selbst Maschinensprache nicht schnell genug – insbesondere wenn man innerhalb der Spiellogik mit verschachtelten Schleifen hantiert. Das Thema Code Optimierung kam daher im Vortrag nicht zu kurz. Drei oder vier gesparte Taktzyklen machen sich sehr bemerkbar, wenn die betreffende Stelle mehrere tausend mal pro Sekunde durchlaufen wird.
Code Optimierung
Obwohl das eigentliche Ziel bei der Spielentwicklung der Erkenntnisgewinn war und es nur an zweiter Stelle darum ging, ein tolles Spiel zu bauen, kann sich das Ergebnis absolut sehen lassen.
Das - fast - fertige Spiel
Nach dem sehr gelungenen Vortrag ging es dann anschliessend in etwas verkleinerter Runde in ein Restaurant, wo weiter gefachsimpelt wurde. Ein rundherum gelungener Abend.
« Vorherige Seite — Nächste Seite »
