Wie im vorherigen Blogpost beschrieben, traten Probleme beim Auslesen der Sensordaten auf. Diese Probleme \u00e4u\u00dferten sich darin, dass der Sensor bei jedem Wert nur 0.0 ausgelesen hat. Die Ausgabe sah dann ungef\u00e4hr so aus:<\/p>\n\n\n\n
21.06.21 12:16:24 (+0200) <sensor> [2021-06-21 10:16:24,005] Speichere Messwerte: { 'X_acceleration': 0.0,\n21.06.21 12:16:24 (+0200) <sensor> 'X_rotation': 0.0,\n21.06.21 12:16:24 (+0200) <sensor> 'Y_acceleration': 0.0,\n21.06.21 12:16:24 (+0200) <sensor> 'Y_rotation': 0.0,\n21.06.21 12:16:24 (+0200) <sensor> 'Z_acceleration': 0.0,\n21.06.21 12:16:24 (+0200) <sensor> 'Z_rotation': 0.0}\n<\/code><\/pre>\n\n\n\nDiese Messwerte w\u00e4ren nat\u00fcrlich perfekt, wenn sich der Sensor nicht bewegt, da somit Ungenauigkeiten in der Messung ausgeschlossen werden k\u00f6nnten. Allerdings traten auch keine Ver\u00e4nderungen durch Bewegung auf, wodurch der Sensor seinen Zweck nicht erf\u00fcllt. Zum Thema der Messungenauigkeit allerdings mehr in einem anderen Blogpost. <\/p>\n\n\n\n
Um den Fehler zu finden und somit den Sensor lauff\u00e4hig zu machen wurde ein systematisches Troubleshooting betrieben.<\/p>\n\n\n\n
Hardware:
Zun\u00e4chst wurde die Hardware auf Fehler \u00fcberpr\u00fcft. Aus vorherigen Experimenten mit einem Raspbian Image konnte bereits best\u00e4tigt 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.<\/p>\n\n\n\n
Software:
Der n\u00e4chste Ansatzpunkt beim Troubleshooting war die Software. Da diese an das bestehende Framework angepasst wurde, musste zun\u00e4chst \u00fcberpr\u00fcft werden, ob Fl\u00fcchtigkeitsfehler bei der Programmierung gemacht wurden. Hierzu wurde zun\u00e4chst in einer Pair-Programming-Session nach Fehlern gesucht, wobei allerdings keine Fehler gefunden wurden. Um die Lauff\u00e4higkeit des Codes zu \u00fcberpr\u00fcfen wurde dieser dann auf eine andere SD-Karte mit einer Raspbian Distribution \u00fcbertragen und dort getestet. In diesem Fall lief der Code und produzierte auch Werte. An dieser Stelle ist der Sensor Code als lauff\u00e4hig 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\u00e4nderte 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\u00e4tekonfiguration zu tun haben k\u00f6nnnte.<\/p>\n\n\n\n
Base Images und Dockerfiles:
Da der Code in einzelnen Modulen l\u00e4uft, wurden diese als n\u00e4chstes Untersucht. Hierzu wurden mehrere M\u00f6glichkeiten ausprobiert das Dockerfile zu gestalten. Hierzu wurden verschiedene Base Images und unterschiedliche Ans\u00e4tze gew\u00e4hlt die notwendigen Abh\u00e4ngigkeiten zu installieren. Als Base Images wurden neben dem Debian Image auch Ubuntu und Raspbian ausprobiert, beide lieferten keine sichtbaren Verbesserungen an der Situation.<\/p>\n\n\n\n
Konfigurationen in BalenaOS:
Im n\u00e4chsten Schritt wurden die Konfigurationen in BalenaOS \u00fcberpr\u00fcft. Mit Device Tree Overlays, die den Zugriff des Kernels auf die Hardware des Systems erm\u00f6glichen, wurde versucht den scheinbar fehlerhaften Zugriff auf den Sensor zu reparieren. Durch die Nutzung einer Vorlage f\u00fcr 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 \u00e4u\u00dferte sich darin, dass Module nicht mehr korrekt gestartet werden konnten oder keine Werte mehr schrieben. Unabh\u00e4ngig von den DT-Overlays h\u00e4tte dies allerdings sowieso kein Problem sein sollen, da durch den Privileged Modus des Moduls jegliche Zugriffe gestattet waren.<\/p>\n\n\n\n
Konfiguration I\u00b2C:
Durch eine einschleichende Ratlosigkeit, wo der Fehler liegen k\u00f6nnte 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.<\/p>\n\n\n\n
root@f2bb9fb94eb9:\/usr\/src\/app# i2cdetect -y 1\n 0 1 2 3 4 5 6 7 8 9 a b c d e f\n00: 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f\n10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f \n20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f\n30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f\n40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f \n50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f\n60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f \n70: 70 71 72 73 74 75 76 77<\/code><\/pre>\n\n\n\n