Blog

Archiv der Kategorie: Blog

Lichts aus, LEDs an

Gestern hat das Projekt Sentient Light einen wichtigen Meilenstein erreicht – die erste Seite der Baumsäule erstrahlt in rund 600 LEDs. 

Aber der Reihe nach: Unter Federführung von Matthias hat das Elektronik Team die Stromversorgung einer Seite des Baums fertiggestellt. Um die 5m langen LED Streifen kontinuierlich mit der benötigten Spannung von 5 Volt zu versorgen, kommen auf jeder der vier Seiten der Säule zwei DC-DC-Wandler zum Einsatz. Diese wandeln die 12 Volt, welche das Netzteil bereitstellt, in 5 Volt um. Die LED Streifen besitzen jeweils vier Einspeispunkte, welche mit 5 Volt versorgt werden.

Verkabelung einer Baumsäule

Bevor die DC-DC-Wandler an der Säule angebracht werden konnten, wurden sie in flammenhämmenden Aufputzdosen platziert und mit Kabeln für Ein- und Ausgänge versehen. Die Kabelstränge wurden anschließend an der Säule hochgeführt und in teils luftigen Höhen an die DC-DC-Wandler gelötet.

DC-DC-Wandler in einer Aufputzdose

Dank der Unterstützung der Baumhaus Crew bestehend aus Simon, Max und Ule konnten wir die erste Baumseite tatsächlich kurz vor Mitternacht zum Leuchten bringen. Bevor der Baum in vollem Glanz erstrahlen kann folgen im Laufe der nächsten Woche die restlichen drei Seiten.

Die Ostseite des Baums

Sentient Light Vision

Sentient Light ist ein generisches System zur reaktiven Ansteuerung von Leuchtelementen dar. Ausgehend von Umgebungsparametern – wie Aufenthaltsort und Bewegungen von Personen – werden Farbe und Intensität einer sich im Raum befindlichen Beleuchtungsinstallationen dynamisch gesteuert. Der Raum wird damit intelligent und in die Lage versetzt, auf die darin befindlichen Menschen zu reagieren. Auf diese Weise entsteht der Eindruck eines fühlenden Raums beziehungsweise eines fühlenden Lichts.

Das Projekt wird derzeit im Baumhaus Berlin realisiert. Das Baumhaus ist ein im Bau befindlicher Veranstaltungsraum in Berlin Wedding für Menschen und Projekte, die sich für den sozialen und ökologischen Wandel engagieren.

sentient light - poster - portrait

Komponenten

Projektziele

Ziel des Projekts ist die Konzeption und Realisierung einer reaktiven Lichtanlage, welche in den Räumen von Das Baumhaus Berlin genutzt werden kann. Die Realisierung umfasst den Entwurf, die Hardware-Fertigung, das Erstellen der Firmware für die Ansteuerung und die Implementierung der Mapping-Engine.

Datenfluss

Die Idee des Projekts ist es, Umgebungsparameter durch Sensoren zu messen und die gemessenen Werte zu einer zentralen Steuerungseinheit zu senden. Die Werte werden dort aggregiert und mittels einer Mapping Engine transformiert.

sentient light - konzept

Datenfluss

Die transformierten Werte wiederum werden an Aktoren gesendet, welche diese als Input für eine Aktion verwenden.

Bluetooth Smart

Sensoren, Aktoren und Steuerungseinheit kommunizieren miteinander über Funk und spannen so ein Netzwerk der Dinge auf. Als Kommunikationsmedium kommt der Funkstandard Bluetooth 4.0 zum Einsatz, auch Bluetooth Low Energy oder Bluetooth Smart genannt. Er zeichnet sich durch einen einfachen Protokollstapel und niedrigen Energieverbrauch der Hardware aus und wird von den meisten Smartphones und Tablets unterstützt.

Sentient Light gewinnt Wettbewerb „Mensch und Technik“ VDI

Genau wie im Vorjahr hat der Verband Deutscher Ingenieure (VDI) Studenten und Studentinnen der Ingenieurwissenschaften an Berliner und Brandenburger Universitäten und Hochschulen zur Teilnahme am Wettbewerb Mensch und Technik aufgefordert. Bis zum 30. September konnten in Form eines Posters und einer Kurzbeschreibung Projekte eingereicht werden die einen klaren Bezug zu Mensch und Technik haben.

Und so nahmen wir den Wettbewerb zum Anlass die längst überfällige Präsentation unseres Projektes anzufertigen. Das ebenfalls für die Teilnahme geforderte Plakat kann demnächst im Baumhaus bewundert werden.

2016_11_17-VDI_Mensch_und_Technik_Poster_v4_de

Sentient Light Poster (klicken für größere Ansicht)

Mitte November bekamen wir die Mitteilung vom VDI dass unser Team zur Preisverleihung eingeladen ist – yeah! Am 25. November fand dann im Ludwig Erhard Haus am Zoologischen Garten die Preisverleihung statt.

SONY DSC

Team Sentient Light und Prof. Hausburg

Zu Beginn der Veranstaltung wurden zunächst die besten Absolventen und Absolventinnen technischer Studiengänge an Berliner und Brandenburger Hochschulen und Universitäten geehrt. Die Oratoren des VDI betonten in ihren Reden die Herausforderungen, durch Technik die Probleme einer modernen und vernetzen Stadt abzugehen und zu lösen. Die Präsidentin der Technischen Hochschule Brandenburg, Prof. Dr. Wieneke-Toutaoui, verwies auf die heutigen Möglichkeiten, als Student eines technischen Studienganges, die Welt ein Stück weit besser zu machen und verwies in dem Zusammenhang auf die zwar gestiegene allerdings noch bei Weitem nicht zufriedenstellende Anteil weiblicher Studenten in Ingenieursstudiengängen.

Die anderen Redner bestärkten die Studenten, ihre Ideen durch Unternehmergeist zu realisieren. Ein Zitat von Reid Hoffman bliebt besonders im Gedächtnis:

„Wenn dir die erste Version deines Produktes nicht peinlich ist, hast du es zu spät auf den Markt gebracht.“

– Reid Hoffman, Co-Founder von LinkedIn

Im Anschluss sollten die drei bestplatzierten Teilnehmer des Wettbewerbs ausgezeichnet werden. Zu diesem Zeitpunkt war usn noch nicht klar, welchen Platz wir belegt hatten.

In umgekehrter Reihenfolge wurden die Preisträger auf die Bühne gebeten: Den dritten Platz belegten zwei Studenten die mithilfe eines Aldebaran Nao Roboters natürlich Sprache in Gebärdensprache übersetzen. Auf dem zweiten Platz landete das Projekt eines einzelnen Teilnehmers, welches zum Ziel hatte, Fluglärm durch die Verwendung von Linern zu reduzieren.

And the winner is…

Sentient Light konnte sich in der Jurywertung durchsetzen und wurde mit dem ersten Platz ausgezeichnet. Keiner von uns hatte zu Beginn mit diesem Erfolg gerechnet. Umso mehr freuen wir uns über diese Ehrung.

In einer kurzen Ansprache beschrieb Professor Hausburg das Projekt als die Integration einer technischen Lösung in ein sozial-dynamisches Umfeld, welche durch seine Dynamik die Interaktionen der beteiligten Personen widerspiegelt.

Im Anschluss an die Preisverleihung hatten die drei Teams die Gelegenheit, ihre Konzepte an einem Stand den anderen Gästen zu demonstrieren. Das steigende Interesse an unserem Projekt nehmen wir zum Anlass, die einzelnen Komponten im Detail vorzustellen. Teil 1: die Projektvision.

Use it, break it, fix it, pick and place it… Maker Faire Berlin 2016

Wie schon im letzten Jahr haben auch in diesem Oktober die Maker Faire Berlin besucht, die nun nicht mehr im Postbahnhof ihre Zelte aufschlägt, sondern in die Station am Gleisdreieck expandiert ist.

IMG_20161003_151559

Gruppenfoto mit dem Maker Bot

Auch diesmal stellten etliche Firmen und Vereine ihre Produkte und Idee vor. Nach wie vor wurden etliche 3D-Drucker in diversen Ausführungen und Pick-and-place-Maschinen demonstriert. Stärker vertreten waren in diesem Jahr Dronen (wie die Crazyflie von Bitcraze), ebenso wie Citizen Science, intelligente Gewächshäuser (wie das sich gerade crowdfundende Projekt fresh square) und Lernmaterialien für junge Bastler (wie der Raspberry Pi basierte Rechner pi-top).

IMG_20161002_164717373

Gewächshaus von Fresh Square

Besondere Aufmerksamkeit erregte der R2 Builders Club,  der originalgetreu nachgebaute durch die Hallen fahren ließ.

IMG_20161002_141859739

R2D2 in Aktion

In Hinblick auf unsere eigenen Projekte könnte der Handschuh Specktr durchaus interessant sein, vor allem in Kombination mit unserer modularen  Sensorlösung Sentient Light.

Eine freie GSM-Masten-Datenbank für offline Standortbestimmung

GPS erlaubt Nutzern von Smartphones und anderen Geräten, auf der ganzen Welt gebührenfrei ihren Standort zu bestimmen. Leider kann so eine Standortbestimmung je nach Witterung bzw. Sichtverhältnis zu den GPS-Satelliten mitunter mehrere Minuten dauern. Um dies zu beschleunigen, kann man auf das „A“ in „AGPS“ zurückzugreifen, das für „Assisted“ steht, die Miteinbeziehung der sichtbaren GSM-Masten in die Standortbestimmung. Welche Masten verfügbar sind, erlaubt praktisch verzögerungslos einen Rückschluss auf die ungefähre Position, die ggf. auch mit unvollständig vorliegenden GPS-Werten verfeinert werden kann.

Für diese Triangulation ist freilich erforderlich, dass man den Standort der jeweils sichtbaren GSM-Masten kennt. Um die Standorte abzurufen, greifen Smartphones ab Werk auf das Internet zu, doch dies bringt einige Probleme mit sich:

  • Es setzt voraus, dass eine Internet-Verbindung besteht.
  • Es erzeugt zusätzlichen, ggf. kostenpflichtigen Traffic.
  • Es öffnet eine Tür für Manipulationen der Standort-Daten.
  • Es ermöglicht dem Provider, den eigenen Standort festzustellen.

Die Lösung ist eine offline-Datenbank, also eine Datenbank aller GSM-Masten weltweit, die der Benutzer bei bestehender Internetverbindung, also z.B. im häuslich WLAN, herunterlädt zusammen mit einer Ersatz-App für den Standort-Dienst (Location Provider), welche anstelle der Internetverbindung die lokale Datenbank nutzt.

UnifiedNlp ist eine solche App und es gibt verschiedene Datenbanken für sie.

Tobias Kuban hat nun auf Github die Datenbanken von OpenCellId und Mozilla Location Services zu einer globalen Karte von GSM-Masten für UnifiedNlp zusammengeführt. Die Datenbank ist entpackt ca. 1 GB groß und kann hier heruntergeladen werden:

Nach dem Herunterladen des Archivs kann es mit xz (Linux) oder 7-Zip (Linux,Windows) entpackt werden:

und bei per microUSB angeschlossenem Smartphone mit adb rübergeladen werden:

Dazu muss noch das UnifiedNlp Frontend und Backend installiert werden, z.B. aus F-Droid.

Android Open Source Release Management Continuous Delivery

Release Management ist ein wichtiges Mittel um effizient der Nutzerschaft neue Versionen einer Software bereitzustellen. Ein Artefakt muss aus einem bestimmten Stand der Quellen erzeugt und in einem geeigneten Repository bereitgestellt werden. Normalerweise wird das Release mit einer informativen Release Note bestückt. Im Fall von Open Source Software gibt es zusätzliche Anforderungen, wie zum Beispiel eine Referenz auf den verwendeten Stand der Quellen und eine Dokumentation.

Ein gutes Release Management erlaubt es, jederzeit ein funktionierendes Artefakt veröffentlichen zu können. Ein solcher Aufbau soll im folgenden für Android  Apps unter Verwendung von Git als Versionsverwaltungssystem, Jenkins als Build Server, Javadoc als Dokumentationswerkzeug und Fdroid als Markplatz zur Veröffentlichung der Apps beschrieben werden.

Unterschiedliche Zielgruppen

Wir unterscheiden in unserem Fall zwischen zwei Gruppen von Nutzern, denen jeweils in unterschiedlichen Zyklen Updates bereitgestellt werden sollen.

Entwickler sollen immer mit dem neuesten Stand einer App und der dazugehörigen Dokumentation versorgt werden. Auf diese Weise kann innerhalb des Entwicklerteams jeder den aktuellen Stand einer App installieren und testen. Dabei muss nicht jeder Stand zwangsläufig ein komplett fertiggestelltes Feature enthalten.
Die Endanwender wiederum sollen nur in den Genuss von ausgewählten Versionen einer App kommen, in der sich mindestens eine spürbare Änderung im Vergleich zur Vorversion befindet.
Im folgenden verwenden wir die Begriffe Release und Dev um die beiden Zielgruppen auseinanderzuhalten.

Unterschiedliche Orte für Fdroid und Javadoc

Um Artefakte und Dokumentation für beide Zielgruppen zu trennen legen wir je ein Fdroid Repository und einen Ort für das Javadoc an. Um sie in Jenkins Jobs einfacher ansprechen zu können, legen wir die Orte in Umgebungsvariablen ab. Die folgenden Variablen werden in der weiteren Beschreibung verwendet:

  • FDROID_REPO_DEV
  • FDROID_REPO_RELEASE
  • JAVADOC_DEV
  • JAVADOC_RELEASE
Dev Konfiguration

Um die Konfiguration möglichst simpel zu halten, verwenden wir pro App einen Jenkins Job der auf jeden push in das Git Repositories reagiert. Im Abstand von wenigen Minuten fragt Jenkins das Git Repository ab und startet folgenden Gradle Aufruf.

  • clean assembleRelease  leert das build Verzeichnis und kompiliert das apk File
  • publishFdroid -Pfdroid=${FDROID_REPO_DEV} -Ppatch=${BUILD_NUMBER} veröffentlicht die App Fdroid Dev Repo und verwendet für den dritten Teil der Versionsnummer die Nummer des Builds
  • publishJavadocRelease -Pjavadoc=${JAVADOC_DEV}  erstellt die Javadoc Dokumentation in einem dafür vorgesehenen Verzeichnis

Als Post Build Action werden die folgenden beiden Artefakte archiviert. Diese werden benötigt um zu einen beliebigen Zeitpunkt einen Stand in das Fdroid Release Repository zu veröffentlichen.

  • app/build/outputs/apk/app-release.apk
  • gradle.properties

Zum einen handelt es sich dabei um das apk File selbst und zum anderen um eine Properties Datei, die weitere Informationen über die App enthält.

Die Werte werden unter anderem verwendet, um die Metadaten des Fdroid Repisitories zu füllen. Bei Bedarf kann die Liste natürlich um weitere Einträge erweitert werden. Wie oben beschrieben wird die Patch Version durch den Parameter patch  von außen gesetzt. Für das Setzen der Versionsanteile Major und Minor ist der Entwickler verantwortlich.

Release Konfiguration

Für die Realisierung der Release Konfiguration verwenden wir das Promoted Builds Plugin. Die Promotion soll nur manuell ausgelöst werden.

Die Release Notes können für die Veröffentlichung im Dev Repo direkt aus jeder Git Commit Message des Commits gezogen werden, der den Build getriggert hat (mehr dazu weiter unten). Für die Release Notes des Release Repos ist das nicht der Fall, da davon auszugehen ist, dass zur Fertigstellung eines Features mehrere Commits getätigt wurden. Aus diesem Grund fügen wir der Promotion den Textparameter RELEASE_MESSAGE hinzu. Auf diese Weise kann ein sprechender, für den Endanwender gedachter Text für das Release angegeben werden.

Da die Promotion zeitlich verzögert also auch erst nach weiteren Commits stattfinden kann, ist der Zustand des Workspace nicht stabil.
Daher müssen im ersten Build Step der Promotion die veröffentlichten Artefakte des ursprünglichen Builds wieder zurück in Workspace kopiert werden. Dafür verwenden wir das Copy Artifacts Plugin. Als Jobname wird der Name des Jobs angegeben dessen App veröffentlicht werden soll, als die Nummer des spezifischen Builds die Variable ${PROMOTED_NUMBER} . Auf die Weise ist sichergestellt, dass genau die Version der App verwendet wird, die zuvor beim automatischen Build erstellt wurde. Gleiches gilt auch für die Metadaten.

Der zweite Build Step der Promotion ist ein Gradle Aufruf, der sich nur minimal von dem des Dev Builds unterscheidet. Die Tasks clean  und assembleRelease entfallen, da das Artefakt schon vorhanden ist. Die Verzeichnisse für das Fdroid Repository und die Dokumentation werden mit den entsprechenden Umgebungsvariablen für die Variante Release angegeben. Zu beachten ist die Verwendung des Parameters message , der den Wert des Jenkins Text Parameters übergeben bekommt.

 Gradle Tasks

Im folgenden wollen wir näher die verwendeten Gradle Tasks und deren Konfiguration eingehen. Wie zuvor erwähnt wir beim Gradle Aufruf die Versionskompente patch von außen gesetzt.

Fdroid

Die Variable fdroidDir beschreibt das Verzeichnis des Fdroid Repositories. Sie muss beim Aufruf gesetzt werden, da sonst sämtlich Fdroid bezogene Tasks übersprungen werden.

Die Variable fdroidMessage kann durch den Parameter message beim Aufruf gesetzt werden, was wie schon erwähnt in unserer Konfiguration bei der Promotion genutzt wird. Sollte message nicht von außen gesetzt werden, wird die Commit Message des letzten Commits verwendet.

  • tidy  entfernt ein Artefakt selben Names aus dem Fdroid Repository
  • copy  kopiert das gebaute apk File in das Fdroid Repository und benennt es enstprechend der Versionsnummer um
  • writeMetadata  beschreibt die Metadata Datei der App. Dabei werden die Werte aus gradle.properties verwendet
  • updateMetadata  aktualisiert die Metadaten
  • publishFdroid  aktualisiert das Fdroid Repository

Javadoc

Die Variable javadocDir beschreibt das Verzeichnis, in das die Javadoc Dokumentation kompiliert werden soll. Das Verzeichnis kann beim Gradle Aufruf durch den Parameter javadoc überschrieben werden. Wird dieser Parameter nicht verwendet, landet das kompilierte Javadoc unterhalb des Projektverzeichnisses.

Er wird pro Build Variante ein Gradle Task in der Form publishJavadoc  erstellt, sodass ein möglicher Aufruf gradle publishJavadocRelease -Pjavadoc=/my/javadoc/dir  lauten könnte.

Fazit

Die Erstellung eines ausgeklügelten Build und Release Mechanismus erfordert meist einen hohen Aufwand, bis sämtliche Schritte funktionieren und alle Rädchen ineinander greifen. Jedoch lassen sich auf diese Weise zeitaufwändige Schritte automatisieren, und neue Versionen per Knopfdruck veröffentlichen. Erfahrungsgemäß lohnt sich die Einrichtung eines Release Mechanismus schon bei wenigen Projekten innerhalb von kürzester Zeit.

Volle Fahrt voraus Interoberlin

Der Frühjahrsputz trägt Früchte : unsere Android Apps sind jetzt mit Javadoc Dokumentationen ausgestattet. Der Blog wird immer internationaler, bis nächste Woche sollten auch die restlichen Posts eine englische Übersetzung bekommen. Unser Fdroid Repo hat jetzt eine neue URL

Ebenfalls bis nächste Woche wollen wir unser Release Management überarbeiten. Basierend auf unserem Build Server Jenkins wollen wir dann präzise bestimmen können, welche Commits zu einem Release werden. Die genaue Konfiguration werden wir beschreiben, sobald sie fertig ist.

Zwischendurch waren wir zu zwei spannenden Sessions im Baumhaus Berlin um zusammen mit Lukas und Oscar das neue Design der Website des Open Space voranzutreiben.

Programmieren im Huddle und das Problem des Versionsmanagements

Ein wirklich präzises Versionsmanagement war an dieser Stelle übrigens nicht möglich, da fast gleichzeitig mehrere Personen an mehreren Dateien des Themes gearbeitet haben. Dabei jede Änderung zu versionieren hätte einen gewaltigen Overhead bedeutet.

Um das versehentliche Überschreiben von Dateien zu verhindern, an denen zwei Entwickler zur gleichen Zeit arbeiten, war in diesem Fall eine ständige Absprache notwendig, die aber nach einer Einspielzeit so gut wie automatisch erfolgte. Wirklich versioniert haben wir die Änderungen nur durch das tägliche Backup der WordPress Instanz.

Frühjahrsputz #tt Session 2015/03/19

Nach einer achtwöchigen Pause, haben wir uns an diesem Donnerstag zur ersten offiziellen #tt Session des Jahres getroffen. Dabei haben wir Pläne und Ideen für den Rest des Jahres gesammelt.

Weiterhin aktuell sind unsere Android Projekte Sauvignon und Lymbo, an denen wir auch in diesem Jahr weiter arbeiten wollen. Auch die BLE Erforschung wollen wir weiter treiben.

Neuer Forschungsgegenstand soll das Container Tool Docker sein, mit dem wir uns ebenfalls beschäftigen wollen.

Weiterhin wollen wir den Open Space Baumhaus Berlin nach Kräften beim Redesign ihrer Webseite unterstützen.

Bevor es aber mit den eigentlichen Projekten losgeht, steht uns ein Frühjahrsputz bevor. Das betrifft vor allem unseren Blog sowie die Dokumentation und das Release Management unserer Android Apps. In Detail wollen wir

  • unseren Blog aufräumen
  • sämtliche Blog Post auch auf englisch veröffentlichten
  • unterschiedliche Fdroid Repositories für Entwicklung und Releases einrichten
  • per Gradle automatisch Javadoc für Android Projekte generieren und veröffentlichen
  • per Gradle Projektdokumentation für Android Projekte mittels LaTeX generieren