Projektarbeit ASURO

Der ASURO war zentraler Bestandteil der letzten Projektarbeit. Das Ergebnis ist eine Betrachtung der Hardware und eine Umsetzung in Software.

Zusammenfassung
In dieser Studienarbeit wurde die Firmware des ASURO Roboters erweitert. Ziel war es, die Sensorwerte der sechs Sensoren zyklisch abzufragen, um die Werte für den Programmierer direkt zur Verfügung zu stellen. Der Controller des ASUROs besitzt einen AD-Wandler mit sechs Messkanälen, deren Aktivierung in der Software koordiniert und deren Messwerte in die realen Werte umgerechnet werden.

Bei den Sensoren handelt es sich um Reflexionslichtschranken, optoelektronische Sensoren, Taster und Batteriespannung. Von den Reflexionslichtschranken kann auf die Umdrehungen der Räder geschlossen werden; von den optoelektronischen Sensoren kann auf die Helligkeit des Untergrunds geschlossen werden. Die Taster dienen zur Kollisionsabfrage an der Roboterstirnseite und die Batteriespannung dient zur Überwachung der Stromversorgung.

Die Abfrage der Sensoren wurde durch zyklische Auswahl der Messkanäle innerhalb der AD-Wandler Interrupt Service Routine realisiert. Die Werte werden in einem öffentlichen struct dem Rest der Roboter Software zur Verfügung gestellt.

Zusätzlich beschreibt diese Arbeit noch die Verwendung der Softwaresimulation in Atmel Studio und eine Methode für Unittests mit AVR Mikrocontrollern.

DOWNLOAD

Sicherheit im Internet der Dinge (Fonera mit SSL)

Sollte es einmal so weit sein, dass sogar der Kühlschrank mit der Heizung und der Waschmaschine spricht um ein möglichst Strom effizientes Miteinander zu gewährleisten, wird das aller Wahrscheinlichkeit nach über Funk passieren. Doch eine Kommunikation über Funk ist alles andere als sicher und so muss der Sicherheitsaspekt von Beginn an in die Entwicklung internetfähiger Haushaltsartikel mit einfließen. Ich experimentiere zur Zeit mit einem kleinen Linuxboard, das unter anderem eine WLAN-Schnittstelle hat.

Sollte dieses Board einmal zum steuern eines Haushaltsgegenstandes verwendet werden, bleibt zu überlegen, wie die Kommunikation von der Kontrollstelle zum Board gesichert werden kann. Eine Möglichkeit wäre das erstellen eines abgeschlossenen WiFi Netzwerks das nur zur Steuerung der Geräte dient und nicht mit dem Internet verbunden ist. Das führt allerdings nicht dazu, dass das Gerät im Internet erreichbar ist, was unserem Ziel nicht gerecht wird. Eine zweite Möglichkeit ist eine normale HTTP Verbindung mit HTTP Auth zu implementieren. Somit ist schon mal eine einfache Sicherheitsebene dazugekommen und das Gerät steht nicht mehr jedem Internetteilnehmer zur Verfügung. Die nächste Schicht wäre eine Verschlüsselte Kommunikation über HTTPS. Dadurch wird das Passwort nicht mehr sichtbar übertragen und einem eventuellen Mithörer bleibt der Anmeldeprozess verborgen. Ein Passwort ist allerdings selten sicher, wenn man dem Benutzer keine vorgegebenen Grenzen setzt. Deshalb bietet sich die Kombination aus Passwort und Zertifikatslogin an. Dabei besitzt der Client ein Public / Private Schlüsselpaar und ein Passwort mit dem das Zertifikat im Client geöffnet werden kann.

Um eine SSL Verbindung über HTTPS zur Fonera zu ermöglichen, benötigt man einen anderen Webserver als den Busybox httpd. Ich habe mich für den mini-httpd entschieden, der bringt auch die Erweiterung für SLL nämlich matrixssl mit. Im OpenWrt Wiki findet sich eine gute Anleitung, wie man mini-httpd mit SSL durchführt. Anders als in der Anleitung angegeben muss allerdings das Paket mini-httpd-matrixssl anstelle von mini-httpd-openssl installiert werden. Ansonsten kann der Anleitung gefolgt werden. Jetzt steht auf der Fonera nur noch  HTTPS mit einem eigenen Zertifikat zur Verfügung. Der nächste Schritt ist nun ein Frontend zu Anmeldung auf der Fonera zu programmieren.

Unit Tests für Mikrocontroller [Installation und Konfiguration für AVR]

Unit Tests sind im PC Bereich mittlerweile Standard. Allerdings ist es schwierig sie auch für Software im Bereich der Mikrocontroller zu verwenden. Die wenigen Ressourcen, die der Mikrocontroller zur Verfügung stellt sollten idealerweise für die Software verwendet werden, die später dann auf dem System laufen soll, denn alles andere wäre Geldverschwendung. Es gibt dennoch die Bemühungen mit so wenig Wasserkopf wie möglich Unit Tests auch auf Mikrocontrollern zu implementieren.
Ich habe das in meinen Projekten bisher so gelöst, dass ich zusätzlich zum normalen Programmcode Testfunktionen implementiert habe. Alles was nur zu Testzwecken im Code eingefügt wurde habe ich mit Präprozessor-Anweisungen eingekapselt, sodass sie bei einem Release Built nicht beachtet wurden. Dadurch habe ich während der Entwicklungszeit die Testfunktionen zur Verfügung und später im 'fertigen' Projekt wurden die Testfunktionen nicht mehr übersetzt. Das führte neben kleinerem Programmcode auch zu schnellerer Abarbeitung von z.B. Interrupt Service Funktionen im fertigen Projekt. In dieser Artikelserie werde ich die Verwendung von µCUnit anhand des ASURO Projekts erklären.