05-19 Erfüllung der Vertragsbedingungen

Heute verbrachte ich meine Zeit mit der Einrichtung von Redis, einem Datenstore. Im Vergleich zu herkömmlichen Datenbanken sind diese wesentlich schneller, da sie Daten im Arbeitsspeicher hinterlegen. Deshalb sind sie bestens geeignet, um Messwerte vom Gateway und Client zwischenzuspeichern. Redis gibt mir die Möglichkeit, über Subscriptions und Publications eine schnellere Programmiersprache als PHP einzusetzen. Somit kann ich später in C oder Golang die Berechnungen ausführen und PHP als REST API Portal an die Aussenwelt benutzen.

Problem

Ich werde zwar alle Bedingungen meines Arbeitsvertrages bis zur Abgabe des Zwischenproduktes abdecken können, aber nur wenn ich einen unsauberen Trick anwende. Grund dafür ist, dass die Zielsetzung für das Zwischenprodukt schlecht formuliert ist und einen Umweg für den gesamten Projektverlauf wäre. Hier nochmal die Zielsetzung:

Ziele bis zum Zeitpunkt der Zwischenpräsentation:

Minimalziel:

• Testnetzwerk mit BLE Server und einem Client, welcher Messdaten an den Server weiterleitet.
• Öffentliche REST API, mit welchem man diese Daten abrufen kann.

Hauptziel:

• Arbeit an der Translation von Signalstärken in Distanzen
• Partielle Lokalisierung eines BLE Gerätes in einem Innenbereich

Warum ich ein Workaround brauche

Partielle Trilateration

Das letzte Hauptziel ist nicht gut durchdacht. Es macht keinen Sinn, bereits an einer Positionsberechnung zu arbeiten. Ich will momentan keine Zeit in etwas investieren, von dem ich mit grosser Sicherheit keine guten Resultate erzielen werde. In sämtlichen Dokumentationsposts habe ich die Ungenauigkeiten der Messungen unterstrichen. Meine Resultate sind sehr ähnlich wie welche aus Berichten von Universitäten und Firmen, welche die Messunsicherheit bestätigen. Es wäre sinnlos, die Trilateration von Clients mit schlechten Messdaten vorzunehmen, da aufgrund der hohen Messunsicherheit der Fehler in trilaterierten Positionen nicht akzeptabel wäre.

Workaround

Zudem stellt sich noch die Frage, was überhaupt der Wert einer partielle Lokalisierung für meine Fragestellung wäre. Denn eigentlich ist die Position bekannt oder sie ist es nicht. Ich meinte mit diesem Satz ursprünglich, dass man die BLE Server quasi als Näherungssensoren brauchen würde. Damit könnte man via der API sagen, ob sich ein Gerät in der unmittelbaren Nähe eines Servers befindet oder nicht. Das ist weder herausfordernd (wenn RSSI > -55 => Gerät ist näher als 1m) noch wirklich interressant, weil nicht die genaue Position des Gerätes kennt. Von mir aus kann ich gerne eine Stunde oder zwei in so was stecken, aber persönlich erachte ich dieses Ziel selbst dann als unerfüllt. Auf Papier würde alles stimmen, doch irgendwie ist es Ehrensache, meine Pflichten korrekt zu erfüllen.

Alle anderen Punkte habe ich bereits abgedeckt. Ich habe ein Testnetzwerk eingerichtet, welcher Arrays von 50 Messungen an der Server ohne Probleme weitergibt. Diese wurden bereits in statistischen Auswertungen gepackt und mit dem Verfahren der kleinsten Quadrate als Funktion beschrieben. Eine Kalibrierungssequenz automatisiert die Ermittlung der Parameter des logarithmischen Pfadverlust-Ausbreitungsmodelles. Mit diesem Modell habe ich Signalstärken in Distanzen umgewandelt.

Sonstige Probleme mit meinem Vertrag

Im Vertrag habe ich die Rauschminderung der Messdaten überhaupt nicht erwähnt. Dabei sind sie ein riesigen Fokus meiner Arbeiten von Mitte und Ende Mai. Obwohl ich schon über Kalman Filterung und Rauschminderung gelesen hatte (Journaleintrag vom 19. März), schrieb ich bewusst nichts über Filtering auf, weil ich mir noch Türen offen stehen lassen wollte. Ich wusste, dass man mit IMU Daten und Dead Reckoning oder Time-Of-Flight Berechnungen Distanzen ermitteln konnte. Nun habe ich mich aber dazu entschieden, mich auf eine reine BLE basierte Lösung zu beschränken. Damit erhoffe ich, dass die Nützlichkeit meines Codes für Entwickler höher ist. Eine Abhängigkeit von weiteren Sensorarten würde meine Zielgruppe verkleinern.

Was ich jetzt mache

Zurzeit erweitere ich das System, sodass der Webserver mehr Clients und Gateways unterstützen wird. Zudem ist das System so ausgelegt, dass Daten kabellos und in Echtzeit (keine Buffer) übermittelt werden. Weil schon nur mit einem Client und einem Gateway 20 Requests jede Sekunde eintreffen, ist die Systembelastung viel höher. Mit Redis subs und pubs kann ich einen Berechnungs-Microservice aufschalten, welcher eigenständig RSSI Daten aufnimmt und verarbeitet. Somit delegiere ich Teile meines Algorithmus an Schichten, welche für einen bestimmten Prozess optimiert wurden.