Troubleshooting bei der Datenerfassung

Wie im vorherigen Blogpost beschrieben, traten Probleme beim Auslesen der Sensordaten auf. Diese Probleme äußerten sich darin, dass der Sensor bei jedem Wert nur 0.0 ausgelesen hat. Die Ausgabe sah dann ungefähr so aus:

21.06.21 12:16:24 (+0200) <sensor> [2021-06-21 10:16:24,005] Speichere Messwerte: {   'X_acceleration': 0.0,
21.06.21 12:16:24 (+0200) <sensor>     'X_rotation': 0.0,
21.06.21 12:16:24 (+0200) <sensor>     'Y_acceleration': 0.0,
21.06.21 12:16:24 (+0200) <sensor>     'Y_rotation': 0.0,
21.06.21 12:16:24 (+0200) <sensor>     'Z_acceleration': 0.0,
21.06.21 12:16:24 (+0200) <sensor>     'Z_rotation': 0.0}

Diese Messwerte wären natürlich perfekt, wenn sich der Sensor nicht bewegt, da somit Ungenauigkeiten in der Messung ausgeschlossen werden könnten. Allerdings traten auch keine Veränderungen durch Bewegung auf, wodurch der Sensor seinen Zweck nicht erfüllt. Zum Thema der Messungenauigkeit allerdings mehr in einem anderen Blogpost.

Um den Fehler zu finden und somit den Sensor lauffähig zu machen wurde ein systematisches Troubleshooting betrieben.

Hardware:
Zunächst wurde die Hardware auf Fehler überprüft. Aus vorherigen Experimenten mit einem Raspbian Image konnte bereits bestätigt werden, dass der Sensor problemlos funktioniert und Daten ausliest. Durch einen erneuten Wechsel der Distribution mit einer anderen SD-Karte konnte wiederholt ausgeschlossen werden, dass der Sensor defekt ist, da auch dieser Versuch realistische Messdaten liefert.

Software:
Der nächste Ansatzpunkt beim Troubleshooting war die Software. Da diese an das bestehende Framework angepasst wurde, musste zunächst überprüft werden, ob Flüchtigkeitsfehler bei der Programmierung gemacht wurden. Hierzu wurde zunächst in einer Pair-Programming-Session nach Fehlern gesucht, wobei allerdings keine Fehler gefunden wurden. Um die Lauffähigkeit des Codes zu überprüfen wurde dieser dann auf eine andere SD-Karte mit einer Raspbian Distribution übertragen und dort getestet. In diesem Fall lief der Code und produzierte auch Werte. An dieser Stelle ist der Sensor Code als lauffähig anzusehen, trotzdem wurden Nachforschungen per Debugger angestellt, um herauszufinden wo die Probleme im gesamten System auftreten. Es konnte zu diesem Zeitpunkt noch nicht ausgeschlossen werden, dass der Code durch die veränderte Umgebung nicht irgendwie beeinflusst wird. Im Debugger Modus wurde dann verifiziert, dass bereits der 1. Schritt im Code, das Auslesen der Rohdaten, nicht funktioniert. Daraus deutete sich an, dass der Fehler etwas mit der BalenaOS bzw. Gerätekonfiguration zu tun haben könnnte.

Base Images und Dockerfiles:
Da der Code in einzelnen Modulen läuft, wurden diese als nächstes Untersucht. Hierzu wurden mehrere Möglichkeiten ausprobiert das Dockerfile zu gestalten. Hierzu wurden verschiedene Base Images und unterschiedliche Ansätze gewählt die notwendigen Abhängigkeiten zu installieren. Als Base Images wurden neben dem Debian Image auch Ubuntu und Raspbian ausprobiert, beide lieferten keine sichtbaren Verbesserungen an der Situation.

Konfigurationen in BalenaOS:
Im nächsten Schritt wurden die Konfigurationen in BalenaOS überprüft. Mit Device Tree Overlays, die den Zugriff des Kernels auf die Hardware des Systems ermöglichen, wurde versucht den scheinbar fehlerhaften Zugriff auf den Sensor zu reparieren. Durch die Nutzung einer Vorlage für den MPU 6050 Sensor sollte erreicht werden, dass die Software auf die Hardware zugreifen kann. Die Nutzung von verschiedenen DT-Overlays brachte allerdings wiederholt keine Verbesserung und funktionierte auch teilweise nicht. Dies äußerte sich darin, dass Module nicht mehr korrekt gestartet werden konnten oder keine Werte mehr schrieben. Unabhängig von den DT-Overlays hätte dies allerdings sowieso kein Problem sein sollen, da durch den Privileged Modus des Moduls jegliche Zugriffe gestattet waren.

Konfiguration I²C:
Durch eine einschleichende Ratlosigkeit, wo der Fehler liegen könnte wurde sich an dieser Stelle wieder zum Anfang der Problems begeben. Der Befehl i2cdetect -y 1 lieferte immernoch eine komplette Tabelle, auf der alle Werte aktiviert waren.

root@f2bb9fb94eb9:/usr/src/app# i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 
20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 
50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 
70: 70 71 72 73 74 75 76 77

Dies sollte nicht der Fall sein, wodurch ein letztendlich auch die Lösung zum Problem gefunden werden konnte. Im letzten Post eines Forumbeitrags https://www.raspberrypi.org/forums/viewtopic.php?t=93222 wurde auf einem Mögliche Interferenz zwischen Modulen aufmerksam gemacht. Um diesen Ansatz nachzugehen wurde dann anschließend das Sensor Modul von den restlichen Modulen getrennt und in einer bereinigten Umgebung gestartet. In dieser Umgebung wurden Daten geschrieben, wodurch klar wurde, dass eines der anderen Module mit der Funktion des Sensors interferiert. Nach weiteren Nachforschungen wurde herausgefunden, dass der StartStopButton des Frameworks die gleichen Pins benutzt wie der MPU6050 Sensor. Durch die Deaktivierung des StartStopButtons, der zu diesem Zeitpunkt im Projekt keinen Nutzen hat, konnte der Sensor auch produktiv in der restlichen Umgebung genutzt werden, wodurch Daten in Echtzeit erfasst und weitergeleitet werden konnten.