Tinkerforge-Basteln Teil 1: Auspacken und Einrichten!

Um meine neuerworbenen Kenntnisse in C++ zu vertiefen, habe ich netterweise etwas äußerst Interessantes auf den Tisch gestellt bekommen. Einen kleinen Karton mit mehreren Elektronikbauteilen, noch in ihren Antistatikbeuteln. (Meine Vorfreude steigt ins Unermessliche.)

 

Worum geht’s?

Tinkerforge ist ein mittelständisches Unternehmen aus Ostwestfalen-Lippe, welches Mikrocontrollerbausteine herstellt, die sogenannten Bricks. Die Idee zu diesen Bricks hatten die beiden Gründer Bastian Nordmeyer und Olaf Lüke, nachdem sie – auf der Suche nach Mikrokontrollermodulen für autonome Fußballroboter – keine entsprechenden offenen, mit verschiedenen Programmiersprachen ansteuerbaren Bauteile gefunden haben. Was 2011 noch mit einer kleinen Produktlinie begann, ist nun ein extensiver Katalog an Controllern (Bricks) und Modulen (Bricklets), die sich in zahlreichen Programmiersprachen ansteuern lassen, und sich durch ihre modulare Bauweise schier endlos verknüpfen lassen.
Neben der Option, sich seine Bricks selbst zusammenzustellen, vertreibt Tinkerforge verschiedene Kits – Komplettpakete für verschiedene Anwendungsmöglichkeiten.
Eines dieser Kits – die Tischwetterstation (für 114,99 €) habe ich zum Austoben bekommen, dazu gab es noch einen WIFI Master Extension Brick (für 29,99€).
In diesem Blogpost wird es um das “Unboxing”, den Zusammenbau, die erste Einrichtung und Codebeispiele von Tinkerforge selbst gehen.

 

Was haben wir denn da?

Hierbei handelt es sich um den Master Brick, Version 2.1. Man kann sich diesen Brick wie die zentrale Verteilerstelle vorstellen. Er hat eine USB-Schnittstelle und hat – neben den stapelbaren Anschlüssen für andere Bricks (Master Extensions, siehe Wifi Extension!) – hat er vier Anschlüsse für Bricklets (siehe Air Quality Bricklet!), und kümmert sich um die Kommunikation zwischen den einzelnen Modulen. Dort wird auch die Verbindung zu einer Recheneinheit hergestellt, die verschiedene Formen annehmen kann, worauf ich später noch kurz eingehen werde. Außerdem ist der Master Brick mit zwei kleinen Knöpfchen an der Seite des USB-Anschlusses ausgestattet, ein Reset-Knopf und ein Erase-Knopf.

Dies ist die WIFI Master Extension, Version 2.0. Dieser Brick kann auf den Master draufgesteckt werden – der Formfaktor ist mit 4×4 cm gleich, euch fallen auch garantiert die Anschlüsse an den Seiten des Bricks auf. Mit diesen Anschlüssen lassen sich mehrere, verschiedenste Kombinationen von Bricks aufeinander stapeln, die das ganze System um zahlreiche Funktionen erweitern können. In diesem Fall, bei der WIFI Master Extension 2.0 handelt es sich um ein Kommunikationsmodul, mit dessen Hilfe sich der Master Brick drahtlos steuern ließe. Bisher hat dieser Brick aber noch nicht die ausreichende Liebe von mir erfahren – da die Wetterstation (noch?) nicht ohne Rechenpower von außen funktioniert, und per USB über den Master Brick mit Strom versorgt werden muss – dementsprechend die Kommunikation bisher größtenteils auch über dieses USB-Kabel lief.

Na, fällt euch schon etwas auf? Dieser Brick ist kein Brick, sondern ein Bricklet, der Formfaktor ist auch deutlich kleiner, mit 2,5×2 cm – es fehlen auch die gerade angesprochenen Anschlüsse zum Stapeln. Dieses kleine Bauteil ist der Air Quality Bricklet, ein interessantes Bauteil, welches mehrere Sensoren an Bord hat. Das Herzstück ist der Indoor Air Quality (kurz IAQ)-Sensor, welcher “flüchtige organische Verbindungen” (Volatile Organic Components, kurz VOC) misst. Diese Messungen werden mit den Messungen der ebenso vorhanden Luftdruck-, Luftfeuchte- und Temperatursensoren kombiniert, um den IAQ-Indexwert zu bestimmen. Laut Tinkerforge braucht es rund 28 Tage Durchlaufzeit für die vollständige Kalibrierung dieses Moduls, ansonsten gilt der IAQ-Indexwert als unzuverlässig. Soviel Zeit habe ich dem Bricklet noch nicht gegeben, aber das kommt auch noch. Angeschlossen wird dieses Sensorpaket – per in dem Tischwetterstationskit enthaltenen 10-Pol- auf 7-Pol-Kabel – an den Master Brick. Insgesamt ist dieses kleine, aber feine Bauteil das, was diese Tischwetterstation zu einer Wetterstation macht.

Ein LCD-Bildschirm! Auf irgendwas muss ich ja schauen können, wenn ich es schon explizit vermeide, aus dem Fenster zu schauen, um zu sehen, wie das Wetter so ist.
Spaß beiseite, dieses Bauteil ist für mich wohl am Interessantesten aus dem ganzen Kit, denn die Möglichkeiten mit einem 2,8″ großem Display mit 128×64 Pixel wären schon unbegrenzt genug – dann hat das wunderbare Ding auch noch einen resistiven Touchscreen! Ich bin sehr gespannt drauf, was für kreative Ideen Ihr (und ich) mit sowas haben könntet (und wie weit die sich von der Grundidee einer Wetterstation entfernen). Wetterstationsschach, anyone?! Das Display wird genauso wie der Air Quality Bricklet über ein 10-Pol- auf 7-Pol-Kabel mit dem Master Brick verbunden.

Wo wir bei Kabeln sind – in dem Paket waren die zwei benötigten 10-Pol- auf 7-Pol-Kabel dabei, und das USB-Kabel, welches zur Stromversorgung und Kommunikation der Recheneinheit mit der Wetterstation dient. Außerdem war auch noch eine Schutzhülle aus gelastertem Plastik, und jede Menge Schrauben dabei. Alles, was das Bastlerherz begehert. Dann öffnen wir all die schönen Dinge mal!

 

Hardware braucht Software

Nach dem Auspacken der Bauteile (mit gebührendem Respekt) habe ich – vor dem großen Zusammenschrauben – die Bricks testen und einrichten wollen. Dazu bietet Tinkerforge zwei Programme an, den Brick Deamon und den Brick Viewer.
Heruntergeladen, Master Brick per USB angeschlossen… es wird nichts erkannt. Hm.
Der Brick Viewer zeigt kein neues Modul an. Nach einigem Grübeln kam’ ich auf die Idee, den Master Brick mit einem RED Brick, den wir (inklusive einiger anderer Module) in der Firma haben, zu verbinden und den (eingerichteten) RED Brick mit meinem Rechner zu verbinden. Damit konnte ich auch den Master Brick im Brick Viewer finden. Den RED Brick abmontiert und den Master Brick wieder mit USB mit dem Rechner verbunden, siehe da, wir haben eine Verbindung. Die anderen Module u. Bricklets ließen sich ganz einfach durch Verbinden mit dem Master Brick ansteuern und die Updates funktionierten auch sehr einfach; allerhöchstens der Prozess den Master Brick auf den neuesten Stand zu bringen ist ein wenig komplizierter als nur auf den Updateknopf im Brick Viewer zu drücken; man muss zuerst den Erase-Knopf auf der Rückseite des Master Bricks gedrückt halten, den Reset-Knopf betätigen und loslassen, und dann den Erase-Knopf ebenso loslassen. Dies versetzt den Master Brick in den Bootloadermodus, dadurch lässt sich dann die neue Firmware über eine serielle Schnittstelle (in meinem Fall USB) aufspielen.

Brick Viewer

Der Brick Viewer ist ein kleines GUI-Tool, mit dem sich die einzelnen Bricks und Module updaten, testen und einrichten lassen.

Jeder Brick hat seinen Eintrag und seinen Reiter, eine UID (wichtig!), eine Position und eine Firmwareversion. Hier kann man sehr unkompliziert beispielweise die WIFI Extension einrichten, und die Kommunikation über diese Verbindung ablaufen lassen.
Hier sieht man den Reiter für den Air Quality Bricklet. Die Werte werden sekündlich geupdatet, und man kann ohne eigenes Zutun schauen, ob die Sensoren das tun, was sie sollen, oder der grundlegende Aufbau der Wetterstation stimmt. Der Brick Viewer sollte für alle Experimente die erste Anlaufstelle sein, da man hier überprüfen kann, ob alles seine “Arbeit” so erledigt, wie es das soll.

 

Brick Daemon

Der Brick Daemon ist ein zentrales Stück Software bei der Ansteuerung der einzelnen Bricks und Bricklets; der Brick Daemon sorgt dafür, dass – egal, welche von den unterstützen Programmiersprachen (eine lange Liste) man für eigene Programme verwenden sollte – die Kommunikation auf TCP/IP-Basis abläuft, sodass mit den von Tinkerforge bereitgestellten APIs sich Bindings ohne Abhängigkeiten erstellen lassen. Seinen Dienst erledigt der Brick Daemon vergleichweise still im Hintergrund, loggt dabei aber auch jede Menge Informationen, Warnungen und Fehler – ein weiteres praktisches Feature, bei dem einem von Tinkerforge einiges an Arbeit abgenommen wurde.

 

Demo-Anwendung!

Nachdem ich alle Bricks getestet habe, und die Station zusammengebaut und -geschraubt habe, habe ich mich gleich auf die ebenso von Tinkerforge bereitgestellte Demoanwendung gestürzt, und auch da – es wäre schwer, mir das Leben noch einfacher zu machen. Die Demo-Anwendung ist in Python geschrieben, und bietet einem eine grundlegende Anzeige, die die Wetterstation allerdings schon voll funktionstüchtig macht. Der Quellcode der Anwendung bietet sogar sehr einfache Optionen, sich seine eigenen Reiter zusammenzustellen – mit eigenen Icons, Funktionen, sogar Bilder lassen sich per Python Imaging Library zur geeigneten Ausgabe auf dem LCD-Bildschirm konvertieren und ausgeben.
Hübsch, oder? Und das ist alles auf der Website von Tinkerforge frei erhältlich – also, der Quellcode, aber auch die Schaltpläne der einzelnen Bricks, für die Elektrobauteiltüftler unter euch.
Ich denke, das sollte erstmal als grobe Übersicht, was für ein Projekt ich auf dem Tisch habe, reichen.

 

Erster Eindruck?

Mein erster Eindruck, bzw. Gedanke, den ich hatte, als ich die Bauteile ausgepackt habe, war: “Jetzt nochmal vierzehn sein, und so etwas unter dem Baum stehen haben. Ich wäre verliebt gewesen.” Nicht, dass das zehn Jahre später bei mir gänzlich anders aussieht. Das, was ich bisher alles mit dieser Wetterstation gemacht habe, und was sich wohl noch machen lässt… eine Plethora an Möglichkeiten, die sich einem öffnet. Die Bauteile, ihre modulare Bauweise, all der Quellcode und die Programme, die einem mitgegeben werden, beziehungsweise welche man auf der Tinkerforgewebsite findet, sind sehr extensiv, und gerade deswegen würde ich sagen, es ist absolut super geeignet für junge, neugierige Bastler und Tüftler mit einer Leidenschaft für das Programmieren und Elektrobauteile. Ich wüsste aber nicht, ob ich selbst rund 120 Euro für so eine Wetterstation ausgeben würde, nur um sie als Wetterstation zu verwenden, das scheint mir – gerade ohne eigene Recheneinheit, die Wetterstation lässt sich ohne RED Brick, Raspberry Pi oder andere Recheneinheiten nicht “standalone” betreiben – ein wenig teuer, wenn ich wirklich nur wissen will, wie warm es gerade ist.
Das scheint mir aber auch wirklich nicht das Anwendungsgebiet dieser Wetterstation zu sein, nein. Die Bauteile, das Set, all diese Dinge sind ganz klar auf Tüftler ausgelegt, und die wirklich sehr hohe Einsteigerfreudlichkeit macht dieses Kit definitiv zu einer Empfehlung für junge Leute ab vierzehn, die mal gerne ihre grundlegenden Programmierfertigkeiten mit einer greifbaren Anwendung verknüpfen wollen. Der Kreativität ist dank des Screens ohnehin schon keine Grenzen gesetzt; die modulare Bauweise würde auch noch viele Erweiterungen für diese Wetterstation unterstützen.
Also, fertigt schonmal die Wunschzettel an, denn nach Weihnachten ist vor Weihnachten.
Im zweiten Teil dieser Blogposts werde ich dann die ersten selbstgeschrieben Anwendungen von mir vorstellen, auf die APIs eingehen, und weitere Ideen besprechen, die ich bislang schon hatte, und auch noch haben werde.

 

Henrik Triem
Henrik Triem
Junior Developer

Henrik is Anwendungsentwickler in Ausbildung, verhindeter Rockstar, kaffeegetrieben und Open Source-begeistert. Zuhause lässt er es auch mal ruhiger mit Tee angehen, entspannt an Klavier oder Gitarre, erkundet neue Musik oder treibt sich mit seinen Freunden in Deutschland herum.

git gud! or: How I Learned to Stop Worrying and Love my Code

(…and I’m only 13 years late to the party…)
First of all, I have a confession to make. I’m code shy. At least that’s what I thought I was.
One of the fresh-faced young trainees this year here at NETWAYS, I’m not entirely “new” to the scene. Having gone to university (with varied success) I never was bestowed with the confidence to actually contribute to anything. In terms of feedback, my lecturers and I only looked at what I was doing wrong – yes, admittedly, to get me to stop what I was doing wrong, but approaching code like this made me feel like I was always doing something wrong.
Again, admittedly, I probably was always doing something wrong, but I felt like I shouldn’t contribute, I mustn’t contribute, the only thing I would add to an open source project would be bugs, I would mess things up more than I would be helpful to anybody. I’ve written some small stuff for myself at home, but.. why would anybody rely on my code?
It was an awful feeling. So I never did contribute. And that’s how I became code shy.
Three months into my stint at NETWAYS, and it all changed massively. Apart from my wonderful colleagues, git helped in a big way to give me more confidence, to be more active in my participation, to instill a kind of pride in my work I haven’t felt before – to stop worrying and love my code.
 

So – why write the millionth paragraph about git?

This won’t be a technical introduction, but rather a little recollection of my thoughts and emotions while getting introduced to git and using it at work – because my mind has been thoroughly blown.
 

What’s git?

Well, let’s take a look at good ol’ Wikipedia:

Git (/ɡɪt/) is a version-control system for tracking changes in computer files and coordinating work on those files among multiple people.

Version-control? Now, what’s that supposed to mean? Is that like back in the days when I sent my source code files to my professor via mail, so he could check over them and see if I did my stuff?
Well, in a way, that could be some sort of version control system as well – just not a very automated and effective one. Version control is about the general management of files, code, data – it keeps track of changes, who did what, when (and if you’re lucky, you’ll even find a hint or two explaining why), and it allows for reversion of changes and modifications people have made.
My ears perked up when I heard this.
I can go around and mess things up and nobody would get mad at me? I won’t break stuff from the get go? I was amazed.
 

But how does git do it?

At work we have remote repositories hosted on GitLab, from which I could pull all of the files of the project onto my local machine. So now I have my own copy of the project, in which I could move, delete, add or modify files to my liking – and I wouldn’t break anything doing so, because the remote repository on GitLab would be completely unchanged.
In a way, it’s a sandbox for me, where I can go ahead and code, take care of issues, fix bugs, or add features, test them – until I feel safe to share the work I’ve done with other people. You can see how that is a comforting feeling to have – you can code without worries.
 

So – what happens behind the scenes?

Git takes snapshots of my work. A snapshot is the way git keeps track of all of the files belonging to a project. Git will checksum them, generate a SHA-1 hash. These hashes are the way git knows about the changes to the code inside the files. After I’ve staged my modified files, I can commit the changes I’ve made. Committing will checksum all of the project directories and store them in the repository – and it will store a pointer to the commit that came before it. This is awesome! So now I can have multiple points to revert the project back to, just in case. But… how would I go about doing that?
Well, let’s talk about branches. Branches are pointers to these commits, the default one being the master branch. There is a master branch on my local machine as well as on GitLab – which made me immediately nervous again. But luckily, I can just branch off of my local master, give it a meaningful name, and even push and store the commits belonging to that branch to GitLab, with the master being untouched. Again, another safe environment for me to go about my work, be more assertive in sharing it, all in a peaceful state of mind.
So – thanks to git, I feel safe in being much more creative and independent when going about contributing to our projects here at NETWAYS – and thanks to the awesome work environment here, I do have space and time to try to add to these projects in a constructive way. My colleagues can look at my code, give me tips and hints, and neither them nor me have to worry about me being a nuisance messing things up.
But what if I’ve finally fixed a bug, or added an awesome feature to one of our projects? Then it’s time to make a merge request. On GitLab, I pick a branch of mine, write a little bit about the new functions or which bugs I (hopefully) fixed, and request for these changes to be added into the master. From there, my fate lies in the hands of the project maintainers…
A successful merge request might just be the greatest feeling of all.
I know that there are a million new ways I could break things if I use git wrongly. So, getting good at git is something I must and will learn at NETWAYS. And – bursting with pride and with a newfound confidence – I look forward to learning more every day.

Henrik Triem
Henrik Triem
Junior Developer

Henrik is Anwendungsentwickler in Ausbildung, verhindeter Rockstar, kaffeegetrieben und Open Source-begeistert. Zuhause lässt er es auch mal ruhiger mit Tee angehen, entspannt an Klavier oder Gitarre, erkundet neue Musik oder treibt sich mit seinen Freunden in Deutschland herum.