Im November 2019 hat der Bundestag das Klimapaket verabschiedet, das unter anderem die Erneuerung der deutschen Radverkehrsinfrastruktur [1] zum Ziel hat. Um sich einen Überblick über den aktuellen Zustand der Radwege zu verschaffen, werden für die Überwachung der Straßenzustände meist teure Messfahrzeuge eingesetzt. Im Bereich der Data-Science-Beratung beschäftigen wir uns als Unternehmen schon seit einigen Jahren mit Themen wie Sensordatenanalyse und Predictive Maintenance. Daher haben wir uns die Frage gestellt, wie diese Themen kosteneffizient kombiniert werden können, um den Straßenzustand zu bewerten. Dies wäre insbesondere für Kommunen interessant, die damit ausgestattete Leihfahrradflotten einsetzen könnten.

Zielsetzung

Das Ziel dieses Projektes ist eine automatisierte fahrradbasierte Straßenanalyse. Dazu müssen die Daten eines Beschleunigungs-, Gyroskop- und GPS-Sensors an einen Klassifizierungsserver übermittelt werden. Es werden verschiedene maschinelle Lernmodelle miteinander verglichen, um eine möglichst hohe Genauigkeit bei der Vorhersage von Straßentypen und -zuständen zu erreichen. Es wird zwischen den Straßentypen Asphalt, Kopfsteinpflaster und Schotter in Verbindung mit den Zuständen glatt, rau und holprig unterschieden, was insgesamt neun Klassen ergibt. Darüber hinaus werden die Ergebnisse mit Hilfe einer IoT-Plattform live auf einer Karte visualisiert.

Verfahren

Der Aufbau dieses Projekts erfordert vor allem zwei Dinge: Daten und ein maschinelles Lernmodell. Die Datensätze sammeln wir selbst, so dass die Frage der Hardwareauswahl für die Sensordatenerfassung eine wichtige Rolle spielt. Für die Klassifikationsaufgabe werden verschiedene Modelle getestet, von baumbasierten Verfahren bis hin zu Deep-Learning-Ansätzen.

Daten

Für die Sensordatenerfassung wurde der Bosch XDK 110 [2] gewählt (siehe mittleres Bild in Abb. 1). Der XDK ist u.a. mit einem Beschleunigungsmesser und einem Gyroskop ausgestattet. Die aufgezeichneten Daten können kabellos über Bluetooth, WiFi oder SD-Karte übertragen werden. Die frei programmierbaren Tasten und LEDs dienen als einfache Benutzerschnittstelle.

Der XDK kann mit der Eclipse-basierten XDK Workbench in C programmiert werden. Weiterhin wird ein normales Trekkingrad verwendet (Bild oben links). Die Halterung des XDK, die auch als Regenschutz dient, wird im Fahrradkorb montiert (Bild unten links). Um die gesammelten Daten zu annotieren, wurde eine App mit dem React Native Framework entwickelt (siehe Bilder rechts). Die aufgezeichneten Daten des XDK werden über Bluetooth an die App übertragen. Außerdem nutzt die App den GPS-Sensor des Smartphones, um die aktuelle Position zu bestimmen. Wenn eine Route kommentiert werden soll, wird der Plus-Button gedrückt, um die entsprechenden Informationen einzugeben.

Einrichtung für die Datenerfassung

Fig. 1: Einrichtung für die Datenerfassung

Auf diese Weise wird ein erster Datensatz erstellt: Über einen Zeitraum von 376 Minuten werden 91 km zurückgelegt und etwa 735.000 Messwerte pro Sensorkanal aufgezeichnet, was einer Abtastrate von 32,5 Hz entspricht. Die Durchschnittsgeschwindigkeit betrug etwa 14,6 km/h.

Um den Einfluss der Abtastrate auf die Genauigkeit unserer Modelle zu beurteilen, wurde ein zweiter Datensatz erstellt, bei dem die Abtastrate maximiert werden sollte. Zu diesem Zweck können die Daten wegen des geringeren Durchsatzes nicht mehr per Bluetooth an die Labelling-App übertragen werden. Stattdessen werden sie direkt auf der SD-Karte gespeichert. Die Tasten und LEDs des XDK wurden entsprechend für das Label sowie für das Starten und Stoppen der Aufzeichnung programmiert. Der zweite Datensatz schließlich umfasst eine Strecke von rund 77 km, die in 314 Minuten aufgezeichnet wurde. Aufgrund der höheren Abtastrate von 294 Hz wurden deutlich mehr Daten aufgezeichnet – etwa 5,6 Millionen Datenpunkte pro Sensorkanal.

Schließlich wurde ein Testdatensatz auf die gleiche Weise aufgezeichnet, wobei das Fahrrad durch ein kvv.nextbike ersetzt wurde, um die Übertragbarkeit der Modelle auf unbekannte Fahrräder zu überprüfen. Insgesamt wurden ca. 9 km gefahren, wobei knapp über 500.000 Messwerte pro Sensorkanal gespeichert wurden.

Maschinelles Lernen

Für den Bereich des maschinellen Lernens wurden verschiedene Modelle verglichen. Zum einen wurden baumbasierte Verfahren wie Random Forest und XGBoost sowie Support Vector Machines gewählt. Alle diese Methoden haben sich bereits als sehr zuverlässige Modelle für eine Vielzahl von Klassifizierungsaufgaben erwiesen.

Darüber hinaus sind baumbasierte Algorithmen recht intuitiv und ihre Entscheidungen lassen sich im Gegensatz zu Black-Box-Modellen leicht interpretieren. Auf der anderen Seite wurden Deep-Learning-basierte Methoden eingesetzt. Neben LSTM-Netzen wurden auch faltige neuronale Netze getestet, insbesondere Deep Residual Networks. Diese wollen wir uns näher ansehen.

Darstellung ResNet für die Klassifizierung von Zeitreihen

Fig. 2: ResNet für die Klassifizierung von Zeitreihen

Die obige Abbildung 2 zeigt ein von Fawaz et al. [3] entwickeltes ResNet zur Klassifizierung von Zeitreihen. Im Vergleich zur Bilderkennung gibt es hier eine Besonderheit: Die Filter gleiten nur in einer Dimension (Zeit) über die Eingabedaten. Alles andere funktioniert jedoch genau gleich. Wir sehen drei Restblöcke, die jeweils drei Faltungsschichten enthalten. Der erste Block verwendet 64 Filter und die beiden anderen Blöcke 128 Filter. Die Restverbindungen können das Degradationsproblem verhindern, d. h. es können tiefere Netze aufgebaut werden, ohne dass die Trainingsgenauigkeit rapide abnimmt. Auf die Restblöcke folgen schließlich ein Durchschnitts-Pooling und eine vollständig verbundene Ausgangsschicht.

Schaubild für Inception Time

Fig. 3: InceptionTime

Mit InceptionTime wird von Fawaz et al. [4] auch der aktuelle Stand der Technik im Bereich der Zeitreihenklassifikation vorgeschlagen. Die Architektur bleibt im Vergleich zum bisherigen ResNet weitgehend unverändert. Es werden jedoch nur zwei statt drei Residualblöcke verwendet. Schließlich werden die einzelnen Faltungsschichten durch Inception-Module ersetzt (siehe Abbildung 3 oben). In diesen Modulen laufen parallele Faltungsoperationen ab, deren Ausgang zu einem gemeinsamen Ausgang zusammengeführt wird.

Die Modelle werden mit Python, scikit-learn und keras implementiert. Zur Optimierung der Hyperparameter wird eine Gittersuche mit zehnfacher stratifizierter Kreuzvalidierung durchgeführt. Zuvor werden die von den Modellen verwendeten Eingabedaten vorbereitet, indem sie normalisiert werden. Außerdem werden zusammenfassende Statistiken wie Durchschnittswerte, Standardabweichungen usw. für die nicht auf Deep Learning basierenden Methoden berechnet. Insgesamt 14 neue Merkmale pro Sensorkanal dienen als Eingabe für diese Modelle.

Ergebnisse

Für den ersten Datensatz konnten die beiden tiefen Residualnetze ResNet und InceptionTime die höchste Validierungsgenauigkeit erzielen, beide erreichten rund 77 %. Der Vorsprung vor dem nächstbesten Modell (CNN-LSTM) beträgt 7 %, alle anderen Modelle liegen unter der 70 %-Marke. Allerdings haben alle Modelle Schwierigkeiten, bestimmte Klassen zu erkennen, und es kommt häufig zu Verwechslungen.

Zwei exemplarische Sequenzen solcher Problemklassen sind im unteren linken Bild zu sehen (Abb. 4). Im oberen linken Bild ist eine Sequenz von rauem Asphalt zu sehen, im unteren linken Bild von rauem Kopfsteinpflaster. Auf der x-Achse sind die Zeitschritte dargestellt, wobei 200 Zeitschritte auch der Sequenzlänge eines Modelleingangs entsprechen. Die y-Achse stellt die Beschleunigung in x-Richtung dar. In beiden Fällen schwanken die Werte in einem ähnlichen Bereich und auch die Periodenlängen sind nahezu identisch, sodass sich die Klassen nicht ohne weiteres voneinander unterscheiden lassen.

Typische Abfolgen von Problemklassen

Fig. 4: Typische Abfolgen von Problemklassen

Eine genauere Betrachtung dieser Klassen führte zu der Vermutung, dass eine höhere Abtastrate die Genauigkeit verbessern könnte. Mit dem Aufzeichnungsaufbau des ersten Datensatzes wurde eine Abtastrate von etwa 32 Hz erreicht. Die durchschnittliche Geschwindigkeit betrug 14,6 km/h oder etwa 4,05 m/s. Im Durchschnitt wurde also alle 12,5 cm eine Messung vorgenommen. Dies scheint recht selten zu sein, wenn man bedenkt, dass z. B. ein Kopfsteinpflaster viel kleiner sein kann. Auch Straßenunebenheiten können häufiger auftreten.

Daher wurde der zweite Datensatz mit einer möglichst hohen Abtastrate erstellt. Auch hier sind zwei Sequenzen der früheren Problemklassen dargestellt (Bild oben rechts in Abb. 4). Diesmal wird nur die x-Achse angepasst. Da die Abtastrate um den Faktor 9 erhöht wird, umfasst die Achse 1.800 Zeitschritte. Es scheint, dass die beiden Klassen nun besser unterschieden werden können, da im Durchschnitt alle 1,36 cm eine Messung durchgeführt wird. Zusammenfassend lässt sich sagen, dass sich die erhöhte Abtastrate als der entscheidende Erfolgsfaktor erwiesen hat. Alle Modelle konnten eine deutlich höhere Validierungsgenauigkeit erreichen; die Residualnetze erreichen sogar Werte um 99 %.

Darüber hinaus sollte die Übertragbarkeit der Modelle auf ein anderes Fahrrad überprüft werden, weshalb der dritte Datensatz aufgenommen wurde. Es ist festzustellen, dass die Daten recht stark vom zweiten Datensatz abweichen. Die Standardabweichungen der Gyroskop-werte unterscheiden sich teilweise um den Faktor 3 bis 4 gegenüber den Trainingsdaten. Folglich können die mit dem zweiten Datensatz trainierten Modelle keine zuverlässigen Vorhersagen machen. Das bedeutet, dass vor der Durchführung dieses Projekts in einem größeren Maßstab, mit vielen Fahrrädern, die Daten aufzeichnen, einige Einstellungen wie Fahrradtyp (insbesondere Federung) und Reifendruck sichergestellt werden müssen.

Schließlich wurde der Aufbau für die Echtzeit-Visualisierung der Sensordaten realisiert. Die Architektur des Testaufbaus ist in Abbildung 5 unten dargestellt. Der XDK ist wie zuvor am Fahrrad montiert und kann die Beschleunigungs- und Gyroskopdaten drahtlos über den WiFi-Hotspot eines Smartphones übertragen.

Gleichzeitig werden die Daten des GPS-Sensors eines Smartphones durch eine entsprechende App aufgezeichnet. Sowohl das Smartphone als auch der XDK veröffentlichen ihre Daten auf einem öffentlichen Mosquitto-Testserver. Dabei kommt das MQTT-Protokoll zum Einsatz, ein Publish-Subscribe-Protokoll für typische IoT-Aufgaben. Mit diesem Aufbau kann das XDK eine Abtastrate von etwa 250 Hz erreichen, während die GPS-Koordinaten aktualisiert werden, sobald sich die Position des Smartphones um mehr als fünf Meter ändert.

Auf der anderen Seite befindet sich ein Computer, der die Klassifizierung und Visualisierung durchführt. Auf diesem läuft ein Mosquitto-Broker, der die Kanäle (topics) des Mosquitto-Testservers abonniert, auf dem die Sensordaten veröffentlicht werden. Dann wird InceptionTime verwendet, um die Daten zu klassifizieren. Anschließend veröffentlicht der Intermediär die Klassifizierungsergebnisse einschließlich der entsprechenden Koordinaten auf einem Kanal, den der Thingsboard-MQTT-Client abonniert hat.

Thingsboard [5] ist eine Open-Source-IoT-Plattform, die die Erfassung, Verarbeitung und Visualisierung von Sensordaten sowie die Verwaltung von Sensorgeräten ermöglicht. Sie wird auf dem lokalen Rechner in Form eines Docker-Containers betrieben. Das XDK und der Intermediär wurden in der Plattform registriert, um sie verwalten zu können. Schließlich werden die abonnierten Sensordaten in einem Dashboard visualisiert.

Einrichtung für die automatische Klassifizierung und Visualisierung

Fig. 5: Einrichtung für automatische Klassifizierung und Visualisierung

Das Bild unten (Abb. 6) zeigt das Dashboard, das in Thingsboard erstellt wurde. Dort ist die aktuelle Position in einer Karte mit einem Marker eingezeichnet. Außerdem werden im Tooltip die Koordinaten und das Klassifizierungsergebnis angezeigt. Zusätzlich wird die gefahrene Route in schwarzer Farbe eingezeichnet. Neben der Karte wird eine Tabelle angezeigt, in der die letzten empfangenen Daten über einen Zeitraum von fünf Minuten aufgezeichnet sind.

Visualisierung der Ergebnisse in Thingsboard

Fig. 6: Visualisierung der Ergebnisse in Thingsboard

Schlussfolgerung

Aus all diesen Ergebnissen sowie aus Vergleichen mit verwandten Arbeiten lassen sich drei wesentliche Lehren ziehen.

Erstens hätte man sich von Anfang an mehr Gedanken über die Abtastrate machen sollen, insbesondere im Hinblick auf die Frage, bei welcher Mindestfrequenz interessante Informationen zu erwarten sind.

Zweitens ist es eine Herausforderung, aber durchaus möglich, eine Straßenklassifizierungsaufgabe wie die vorliegende kostengünstig und vollautomatisch durchzuführen. Der Einsatz modernster Machine Learning Algorithmen führte daher zu sehr beeindruckenden Klassifikationsergebnissen. Damit konnte ein praxistaugliches Modell geschaffen werden – primär in Verbindung mit der automatisierten Übertragung, Klassifizierung und Visualisierung der Daten.

Drittens: Um ein robustes Modell zu erstellen, sollte bei der Erhebung der Trainingsdaten eine große Anzahl unterschiedlicher Strecken, Fahrräder, Radfahrer, Luftdrücke und Geschwindigkeiten berücksichtigt werden.

Links

[1]: https://www.adfc.de/neuigkeit/klimapaket-zu-wenig-aber-ein-erfolg-fuer-den-radverkehr/

[2]: https://www.xdk.io/fileadmin/user_upload/XDK110_QuickStartGuide.pdf

[3]: Fawaz, H. I.; Forestier, G.; Weber, J.; Idoumghar, L.; Muller, P.-A.: Deep learning for time series classification: a review. Data Mining and Knowledge Discovery 33/4, S. 917–963, 2019.

[4]: Fawaz, H. I.; Lucas, B.; Forestier, G.; Pelletier, C.; Schmidt, D. F.; Weber, J.; Webb, G. I.; Idoumghar, L.; Muller, P.-A.; Petitjean, F.: InceptionTime: Finding AlexNet for Time Series Classification. arXiv preprint arXiv:1909.04939/, 2019.

[5]: https://thingsboard.io/docs/iot-gateway/what-is-iot-gateway/

Diese Themen könnten Dich auch interessieren

Symbolbild für Domainlifecycles Code Generator (DCG)

Ein Generativer KI-Assistent für Domain-Driven Design

Hier erfährst Du, wie der KI-Assistent für Domain-Driven Design „Domainlifecycles Code Generator“ funktioniert und entwickelt wurde.
Schmuckbild zum Thema Chatbot Assistenten durch Nutzung von LLMs und Retrieval Augmented Generation

Chatbot Assistenten durch Nutzung von LLMs und Retrieval Augmented Generation

Wir erläutern die Architektur eines Chatbots, der durch die Nutzung von LLMs und Retrieval Augmented Generation schnell und effizient auf Fragen antwortet.
Eine Person analysiert eine Datenauswertung auf dem Bildschirm eines MacBooks.

Revolution in Real-time Analytics: Wie Tiered Storage Dateneffizienz transformiert

Wir zeigen Dir, welche Auswirkungen Speicherstrategien in Bezug auf Real-time Analytics haben.

Nimm gerne Kontakt zu uns auf!

Hast Du Fragen zu unseren Ideen, Konzepten oder Abschlussarbeiten? Dann freue ich mich immer über den Austausch mit Dir!

Sende mir gerne eine Mail, vernetze Dich mit mir oder hinterlasse Deine Kontaktdaten.

Simon Kneller, Senior Consultant, Industrial Analytics & IoT

Simon Kneller
Head of Industrial Analytics & IoT