Montag, 25. April 2016

Temperatur messen ist meistens einfach ...


aber nicht immer.

Hier geht es darum, die Temperatur der Keramikleisten an einem Saugkasten zu messen. Da kommt man leider gar nicht gut ran, der rote Pfeil zeigt auf eine solche Leiste (das kleine graue "Ding" zwischen der blauen und der bräunlichen Kante (kann man kaum sehen). Das Problem dabei ist, dass auf dieser Leiste das Formiersieb (das hier im Bild am roten Pfeil schräg nach rechts oben verlaufende "Ding") läuft. Und zwar im Betrieb ziemlich schnell, da ranzukommen wäre gar keine gute Idee. Das ist übrigens die Leiste, an die man am besten rankommt, die anderen, zum Beispiel am blauen Pfeil, kann man hier im Bild überhaupt nicht erkennen ...

Um besser zu verstehen, was an einem solchen Saugkasten wirklich passiert, will ich die Temperaturen an mehreren Stellen messen, aber zunächst brauche ich ein Gefühl dafür, in welchem Bereich sich das ungefähr bewegt. Also ein Vorversuch. Im Prinzip ganz einfach, Kontaktthermometer mit langem Arm, an dem ein präziser, kleiner Fühler hängt. Gibt's bestimmt irgendwo zu kaufen, die Frage ist bloß wo und für wie viel.

Solche Thermometer mit einem 10cm langen Fühler gibt's an jeder Ecke, das hilft hier bloß nichts, man kommt nicht so nahe ran (es sei denn, man hat ernsthafte Ambitionen, vorzeitig aus dem Leben zu scheiden oder zumindest einen Arm zu opfern ...

Also selber basteln. Wie üblich ;-) Das Ergebnis:


Wunder der Globalisierung, das Material hat grade mal 20 € gekostet. Ein Miniatur Pt100, dazu ein Einbauinstrument zur Temperaturmessung und ein bisschen Kram aus der Bastelkiste. Das Interessante ist der Fühler selber. Die thermische Trägheit des Fühlers soll möglichst klein sein: Die Keramikleiste hat einen Querschnitt von vielleicht einem Quadratzentimeter und ist schön glatt poliert. Mit einem großen Fühler im Metallgehäuse kühlt man vermutlich eher die Leiste ab, als deren Temperatur zu messen, zumindest, wenn der thermische Kontakt gut ist und lang genug hält. Das ist aber gar nicht so einfach, da man das Ganze ziemlich freihändig einen Meter vom Körper entfernt möglichst ohne zu wackeln an die Leiste hält.

Um diesen Balanceakt zu erleichtern, eine spezielle Fühlerkonstruktion:

Der Messkopf (zum Größenvergleich die Pfote meines Katers) besteht aus einer dünnen Kupferscheibe (etwa 100µm dick, 10mm Durchmesser), auf der der PT100 (etwa 2x2x1mm) befestigt ist. Dieser Kopf ist mit einem Stückchen Silikonschlauch mit der Elektronik verbunden. Durch diese etwas elastische Kopplung ist es möglich, die Kupferscheibe vollflächig an die Leiste zu drücken, auch wenn man den richtigen Winkel nicht ganz trifft (man sieht ja nicht hin ...) und dabei eine möglichst große Kontaktfläche zu haben (dann kriegt man möglichst schnell Leiste und Fühler auf die möglichst gleiche Temperatur).

Da Silikon grundsätzlich schlecht zu kleben ist (hier zwar mit einem speziellen Silikonkleber, aber trotzdem ...), sollte man das mit der Elastizität nicht übertreiben, gedacht ist es ja, um einen Winkelfehler von vielleicht fünf Grad zu kompensieren. Die erste Version habe ich ein paar Ingenieuren überlassen, die den Messkopf prompt zerstört haben. Auf meine Frage, wieweit sie den Kopf gebogen haben, lautete die Antwort: "So weit, wie es ging". *arrrghhhhhhhh*


Montag, 11. April 2016

KI und so


IBM versucht ja seit einiger Zeit, mit dem Watson-Portfolio KI-Anwendungen in verscheidenen Branchen in den Markt zu bringen. Aktuell mit der Emotional Analysis API, einer Linguistik-Engine, die eine Persönlichkeitsanalyse aus einem Textmuster erzeugt.

So etwas gibt es ja schon lange, das kommerzielle Ziel ist (natürlich) effektivere Werbung, siehe den obigen Screenshot aus der Demo. Nur meistens funktioniert das nicht besonders gut. Um rauszufinden, ob es sich lohnt, Zeit zu investieren und gründlicher zu testen, wie gut das System funktioniert, habe ich mal mein letztes Paper analysieren lassen (eigentlich sollte man einen Text über Alltagsthemen verwenden, andererseits sind Industrie 4.0-Ansätze in der Papierindustrie heute ja ein Alltagsthema ;-)

"sceptical and strict", "imaginative", "intrigued by new ideas" sind ja durchaus Attribute, die einer wissenschaftlichen Arbeit zu stehen. "unconcerned with helping others" folgt hoffentlich nur aus der sachlichen Natur einer solchen Veröffentlichung ;-)

Jedenfalls scheint das Ergebnis mehr als zufällig zu sein, ich werde wohl in den nächsten Wochen (theoretisch bin ich im Forschungssemester und habe Zeit für solche Sachen ;-) ein bisschen mehr Zeit mit diesem System verbringen.

Anwendungen gibt es dafür ja viele, von der Früherkennung von Problemen bei der Analyse von Besuchsberichten von Außendienstlern (das ist das, was mich am meisten interessieren würde) bis zur massenhaften Untersuchung von emails nach anderen Kriterien, vielleicht "Likely to be a terrorist".

Freitag, 3. Juli 2015

Mal was ganz anderes ....


ich habe heute aus aktuellem Anlass den Nachmittag über mit dem neuronalen Netz von google rumgespielt, das Bilder "träumen" kann .... cooler Stoff. Allerdings ging das nicht ganz ohne Probleme ab: Grundsätzlich schon so, wie in der Anleitung, aber nachdem endlich alles installiert war (also nach etwa zwei Stunden) stürzte python immer beim import von caffe mit einer segmentation violation ab.

Nach einigem suchen stellte sich raus, dass das daran liegt, dass die mit dem Betriebssystem (Mac OS X 10.10) mitgelieferte python Library (natürlich) nicht zur aktuellen, installierten python Version (2.7.10) passt. Abhilfe: Die System-Libraries ausser Gefecht setzen (/System/Library/Frameworks/Python.framework umbenennen und durch einen Link auf die aktuelle Version ersetzen, bei mir /usr/local/Cellar/python/2.7.10/Frameworks/Python.framework/) und schon geht's.

Dafür funktioniert jetzt iPhoto nicht mehr, das will nämlich die alte Version *grrrr*

Mittwoch, 1. Oktober 2014

Ingestion rates


Im September gab es eine (durchaus interessante) Veranstaltung in Stuttgart, die mongoDB IoT european city tour. Thema war, ob (na ja, also natürlich "das") mongodb die ideale Basis für das Internet of Things sei. Dabei ergab sich die Gelegenheit, einen der Chief sonstwas Architects von mongodb zu fragen, warum (zum Geier) man denn eine (dokumentenorientierte) NoSQL-Datenbank braucht, um sehr einfach strukturierte Sensordaten zu speichern. Nach meiner unmassgeblichen Ansicht ist eine relationale Datenbank hier viel besser geeignet.

Die Antwort war: "Ingestion rate" (nach einigem Nachdenken kam dann noch "If you want to annotate your data ...", das ist ein guter Punkt, aber halt nur, wenn man das dann auch in unstrukturierter Form machen will. Und nach noch längerem Nachdenken "Open Source").

Also "Ingestion rate". Das Lieblingswort der NoSQL-Anbieter, wie mir scheint. Solche Aussagen wecken immer ganz schnell meine Neugier. Also habe ich die Zeit vor Semesterstart für einen kleinen Benchmark genutzt.

Das Szenario ist einfach: Eine Anzahl von Sensoren, die Daten liefern, beispielsweise 100 Sensoren, die ein paar Mal pro Sekunde einen Wert (etwa einen Ort oder eine Geschwindigkeit) liefern. Gespeichert wird für jede Messung die Zeit, der Wert, die Art des Werts und die ID des Sensors. Alles ints. Transaktionen brauchen wir hier eigentlich keine, da keine Werte geändert werden. Die einzigen Operationen sind das Anlegen neuer Datensätze und Lesen bereits bestehender.

Zunächst in einer mysql-Datenbank. Ein INSERT pro Wert, MyISAM-Engine. Kein Index. Dann mongoDB. Zunächst auch ein Wert pro insert, dann bulk-insert mit jeweils 1000 Werten. Auch ohne Index. In der Realität werden hier also die Zahlen schlechter (also langsamer) werden, denn ohne Index dauert es viel zu lang, die Daten zu finden.

Wenn man sich mal genauer überlegt, was man in diesem Fall eigentlich braucht, dann kommt man (hoffentlich) früher oder später darauf, dass eine Datenbank eigentlich overkill ist: Eine Zeitreihe kann man leicht in einer (Binär-) Datei speichern. Das Einfügen (also hier ja nur ein Anhängen) geht einfach. Suchen ist etwas schwieriger. Die typischen Abfragen in einem solchen System sind "Gib mir die Werte aus einem bestimmten Zeitintervall", beispielsweise den letzten zehn Sekunden usw.

Wenn hier jeweils die ganze Datei durchsucht werden muss, dann ist das viel zu langsam. Also braucht man einen Index. Da man in der Regel aber sowieso aggregierte Werte haben will, um die Darstellung auf unterschiedlichen Zeitskalen zu beschleunigen, ist das gar nicht so schwierig: Man speichert sowieso nicht nur die Originaldaten, sondern dazu noch Mittelwerte (und ggf. andere Verteilungsparameter) je Sekunde, Minute, Stunde, Tag usw. Wenn man hier jeweils noch die (ungefähre) Position dieses Intervalls in der grossen Datei mit den Originaldaten speichert, hat man eine Art B*-Baum für Zeitreihendaten. Der oberste Knoten sind die Monate(oder Jahre oder wasauchimmer). Auf der nächsten Ebene kommen die Tage, dann die Stunden, dann die Minuten, dann die Sekunden, dann die Daten. Sucht man die Daten für einen bestimmten Zeitpunkt, fängt man oben an, kommt so zum richtigen Tag, dann zur richtigen Stunde, zur Minute, zur Sekunde und schliesslich in die Datei, wo man einen Block oder so liest und die Daten hat. Programmieraufwand so in der Größenordnung von ein paar Tagen.

Das Ergebnis ist beeindruckend: MySQL und mongoDB liegen eher nah beieinander, MySQL etwa doppelt so schnell wie mongoDB. Beide in der Größenordnung (genauer ist das eh nicht, wir wollen ja nur ungefähre Zahlen haben) von 10.000 Datensätzen pro Sekunde.

Die "handgestrickte" Version mit Dateien (hier wurde nur der Index für die Sekunden realisiert, die oberen Ebenen wurden, da für die Performance irrelevant, weggelassen) schafft etwa 2 Millionen Datensätze pro Sekunde, also etwa 200 mal mehr als die Datenbanken !

Interessant ist hier, dass der bulk insert bei mongoDB praktisch keine Verbesserung bringt (bulk inserts scheinen ein schwieriges Thema zu sein, siehe etwa hier und hier).

Wenn man bei den Datenbanken noch Indices verwendet, muss man sehr ausfpassen, dass die Performance nicht in den Keller geht (siehe etwa hier).



Also: Wegen "Ingestion rate" braucht man keine NoSQL-Datenbank !



Üblicherweise kommt dann der Einwand, dass man NoSQL-Datenbanken leichter verteilen kann und so eine bessere Performance erzielen kann. Einen interesasanten Benchmark mit verteilten MySQL-Datenbanken, bei dem 15 Instanzen etwa 1 Million Datensätze pro Sekunde schaffen, gibt's hier.
Die schaffen etwa 150.000 pro Sekunde, was ganz gut zu meinen Messungen passt: Ich habe mein 4 Jahre altes Macbook verwendet, die hatten eine dicke Amazon Instanz. Passt.

Braucht man mehr Performance muss man in jedem Fall verteilen. Das ist dann aber schon ganz schön viel: Nehmen wir mal an, dass ein vernünftiger Rechner mit SSDs den zehnfachen Durchsatz wie mein altes Macbook schafft (das ist eher konservativ), dann wären das immerhin 20 Millionen Datensätze pro Sekunde .... die muss man erstmal haben.

Falls jeder Sensor pro Sekunde einen Datensatz liefert (das sind so übliche Szenarien, etwa auch bei der IoT-Veranstaltung die intelligenten Akkuschrauber von Bosch), dann sind das 20 Millionen Sensoren .....

Aber in der Tat, es gibt Anwendungsfälle, wo man so viele hat (etwa bei TelCos). Dann sind verteilte Dateisysteme notwendig, ein schönes Beispiel mit 100 Millionen Datensätzen pro Sekunde gibt's hier.

Also nochmal: Wegen Ingestion rates braucht man keine NoSQL-Datenbank ! Zumindest in einem IoT-Szenario, bei komplexen Dokumenten mag das wohl sein. Haben wir hier aber nicht ! Nein !

Bleibt also noch das Argument mit der Annotation. Bei Sensordaten kann man hier zwei Grenzfälle sehen: Bei Massendate die Annotation mit Events. Das also aus anderen Quellen stammende oder durch Auswertungen erzeugte Informationen über besondere Ereignisse (etwa die Überschreitung von Grenzwerten oder die Clusterung von Daten) hinzugefügt werden. Das geht mit relationalen Datenbanken natürlich hervorragend. Einfach eine zusätzliche Tabelle angelegt, die per Fremdschlüssel auf die entsprechenden Datensätze verweist.

Der andere Grenzfall wären meistens manuell erstellte, in jedem Fall aber unstrukturierte Daten in unvorhersehbarer Form. Die kann man tatsächlich gut in NoSQL-Datenbanken speichern. Die Frage ist, was bringt das ? Unstrukturierte Daten auszuwerten ist, insbesondere wenn man überhaupt nicht weiss, worum es sich handelt, gar nicht so einfach. Da bleibt eigentlich nur eine Volltextsuche, semantische Textanalyse usw. Das kann man aber auch mit einer relationalen Datenbank gut machen, wenn man diese Annotationen als BLOB speichert.

Bleibt "Open Source". Ist MySQL auch. Zumindest die Community Edition. Wie bei mongoDB auch.

Was bleibt also von den Argumenten übrig ?

Nix.

Den Quellcode der verwendeten Programme gibt's hier.

Mittwoch, 2. Juli 2014

Wie in der guten alten Zeit ...


Von Intel gibt es ganz neu einen sehr schicken - na ja, was eigentlich - sagen wir mal Barebone (heisst NUC - Next Unit of Computing). Der ist wohl eigentlich für Kassensysteme oder Infoterminals gedacht: Sehr niedriger Stromverbrauch, sehr niedrige Rechenleistung, ohne mechanische Teile, also lüfterlos, 4GB Flash intern, VGA-Anschluss und, man höre und staune: eine serielle Schnittstelle.

Also ideal für embedded-Anwendungen wie das NBS. Die ideale Basisstation. Bisher war das ja ein Raspberry Pi mit einem LCD-Display, aber wenn man den Aufwand für das Gehäuse, Netzteil usw. mitrechnet, dann ist die Intel-Kiste ein Schnäppchen: Ohne RAM für etwa 140 Euro, insgesamt also etwa 180.

Bleibt die Frage nach dem Betriebssystem. Linux natürlich. In diesem Fall Lubuntu, ein Ubuntu für Systeme mit wenig Resourcen. Also nix wie los. Aber da gibt es ein Problem: Ich möchte natürlich keine separate Festplatte installieren, sondern das Betriebssystem auf das interne Flash packen.

Leider sagt Lubuntu bei der Installation aber, dass es mindestens 4,3 GB braucht *grrr* Das eigentliche Image braucht nämlich nur 2.3 GB. In den Anleitungen im Netz findet man überall, dass man die Größenberechnung patchen soll. Das hat bestimmt mal mit irgendeiner Version funktioniert .....

Die Lösung ist aber einfach: Letztlich muss man nur den Installer dazu bringen, trotz vermeintlich zu knappem Platz weiter zu machen. Und das erreicht man, indem man die Fehlerbehandlung dieses Problems (siehe oben, im File ubi-prepare.py) aehm, sagen wir mal, modifiziert:

In Zeile 102 einfach True statt False, dann läuft der Installer munter weiter .... wer bremst verliert ;-)

Und noch ein Versuch


Die Bewegungserkennung mit der-Maus-Kamera funktionierte im Labor zwar sehr gut, unterm dunklen Auto in der Tiefgarage allerdings nicht mehr. Zumindest ohne Beleuchtung wird das wohl nichts.

Da ich sowieso einen IR-Temperatursensor ausprobieren wollte, war das die Gelegenheit. Auch hier war das nicht besonders kompliziert, der Beispielcode funktionierte sofort. Beeindruckend ist die Auflösung, eine Hand in einem halben Meter davorgehalten erkennt der Sensor sofort, die Hauttemperatur wird mit etwa 30 Grad gut gemessen. Der einzige Hinderungsgrund, den Sensor für das Bewegungserkennungsprojekt einzusetzen, ist der Preis, etwa 20 Euro.

Da die Inbetriebnahme viel schneller ging, als gedacht, haben wir noch ein bisschen mit dem Sensor experimentiert: Unterschiedliche Materialien haben eine unterschiedliche Emissivität. Soll etwa die Temperatur einer (auch Infrarot spiegelnden) Metalloberfläche gemessen werden, wird das mit dieser Art Sensor schwierig.

Zum experimentieren verwendeten wir ein Stück Aluminium, auf der einen Seite blank poliert, auf der anderen mattschwarz lackiert. Man kann natürlich bei der Berechnung der Temperatur die Emissivität einstellen (sowohl beim verwendeten Sensor als auch bei dem als Kontrolle verwendeten IR-Thermometer), das löst aber das Problem nicht: Die von der Umgebung (in diesem Fall vom Experimentator) ausgehende Strahlung wird von der Metalloberfläche reflektiert. Man muss also sehr genau aufpassen, welche Temperatur man misst. Das ist kein (allzu grosses) Problem, wenn das zu messende Objekt sehr viel heisser ist als die Umgebung (die Temperatur geht in der vierten Potenz in die Sensorspannung ein), bei ähnlicher Temperatur (bei uns etwa 30 Grad Umgebung vs. gut vierzig Grad am Messobjekt) ist das praktisch aussichtslos.

Fazit: Geht, aber zu teuer. Den nächsten Versuch machen wir mit Ultraschallsensoren. Nächstes Mal ;-)

Dienstag, 24. Juni 2014

Eine sezierte Maus ...



kann mehr Freude machen als man denkt, Mikroschalter, Lichtschranken und vor allem eine Kamera. Zwar beschränkt in der Auflösung (typischerweise 18x18 Pixel, schwarzweiss, also nix für die Videokonferenz) aber manchmal ist das ja von Vorteil. 

Nämlich dann, wenn man keine "Bilder" fotografieren will, sondern nur ein paar Helligkeitswerte unterscheiden muss.

Im Rahmen unserer Summerschool "physical computing" hatte ein Student die Idee, den Kofferraum seines Autos berührungslos zu öffnen. Heißt durch Gesten, in diesem Fall mit dem Fuß, weil die Hände in dieser Situation ja oft bereits belegt sind. Den Auto-spezifischen Teil (wie öffnet man den Kofferraum, wie sorgt man dafür, dass das nur im Stillstand passiert usw.) hatte er sich schon überlegt, aber die Erkennung der Geste war noch ein ungelöstes Problem. Also genau das richtige für uns ;-)

Nach einer Weile brainstorming kam die Idee auf, dieses Problem optisch zu lösen, nicht mit einer Webcam, das wäre zwar einfach, aber man braucht eine ganze Menge Rechenleistung, sondern mit der Kamera aus einer optischen Maus und einem (stromsparenden und schnell bootenden) Arduino.

Wir sind natürlöich nicht die ersten, die sich mit dem Innenleben einer Maus beschäftigt haben, wir sind nach dieser Anleitung vorgegangen, da die Jungs dort den Code freundlicherweise schon an den auch in unserer Maus vorhandenen Kamerachip ANDS2610 angepasst hatten. Funktionierte auch (beinahe wider Erwarten) sofort.

Man muß eigentlich nicht viel tun: Die Maus ihres Gehäuses entledigen und die beiden Leitungen der seriellen Schnittstelle zwischen dem Optik-Chip und dem Controller in der Maus auftrennen und mit zwei Ports eines Arduino-Controllers verbinden. Fehlt noch die Stromversorgung, die auch der Arduino übernimmt, das war's.


Im ersten Versuch liest der Arduino nur die Daten vom Kamera-Chip und überträgt die dann per serieller Schnittstelle an den angeschlossenen PC. Dort läuft ein Processing-Sketch, der die Daten grafisch darstellt und auswertet. Im Versuchsaufbau ersetzt ein schwarzer Laptop-Deckel den Asphalt des Parkplatzes, die wischende Hand wird problemlos erkannt: Der Processing-Sketch berechnet pro Bild (zwanzig pro Sekunde) die mittlere Helligkeit und daraus dann einen gleitenden Mittelwert über hundert Bilder. Ist die Abweichung des aktuellen Bildes größer als eine Schwelle, ist was passiert.


Funktioniert ! Im Labor. Schau mer mal, wie das dann aussieht, wenn der Sensor in die Stosstange des Autos eingebaut ist.