Ausgabe 36 · Juni 2023

Diesen Artikel als PDF

Erschütterungsmessungen und deren Auswertung

von Olaf Schultz

Wie stark sind die Vibrationen, denen Fahrradfahrende auf unterschiedlichen Wegeoberflächen ausgesetzt sind? Durch die Betreuung des in der Ausgabe 35 erschienenen Artikels »Radweganalyse per Smartphone« von Uwe Scholz und Maik Pertermann wurde ich selbst aktiv.

Das eigentliche Ziel hier ist eine konfigurierbare grafische Auswertung (Beschleunigung in einer »Kartendarstellung«) und eine Statistik, um eine Argumentationshilfe für die Radverkehrsplanung und Wegeinstandsetzung liefern zu können. Es geht um Fahrkomfort, »MAK«-Werte etc., auch wenn hier (nach meiner Kenntnis) noch keine Anforderungen für Radverkehrsanlagen festgelegt sind.

1988 hat Rainer Pivit in der Pro Velo, Ausgabe 11, über die vergleichenden Messungen der Fahrradforschungsgruppe der Uni Oldenburg (Oldb) berichtet. Die Bewertung war damals »katastrophal«. Zu der Zeit war der Aufwand bei den Messungen deutlich größer als heute. Nun haben viele Radfahrer die Messtechnik in Form des Smartphones meistens eh mit dabei.

Die Messdaten werden mit der kostenlos verfügbaren Android-App phyphox (RWTH Aachen) erhoben.

Für die Konvertierung und Auswertung kommt hier als Script-/Programmiersprache awk und für die Darstellung gnuplot zur Anwendung. awk und gnuplot sind für nahezu alle Betriebssysteme (auch Windows) verfügbar. Hier wird es auf Linux-Systemen verwendet. Für die Darstellung habe ich bisher kein anderes Programm gefunden, das in einer Karte die Beschleunigungen als Track gut darstellen kann, geschweige denn, dass es eine konfigurierbare und übersichtliche Auswertung erlauben würde.

Thomas Zastrow hat einen weiteren vielversprechenden Weg mit anderen Schwerpunkten bei Auswertung und Darstellungen mit Python und diverse Module entwickelt.

In Bild 1 ist eine mögliche Ausgabe mit einigen händisch hinzugefügten Beschriftungen der Wegearten wiedergegeben – es soll als Vorschlag dienen. Die Punktegröße und -farbe zeigt die Beschleunigungen an, die Dichte zeigt die Häufigkeit. Das wäre ein Format für Papierausgaben gegenüber z. B. Ämtern. Hier »anonymisiert« auf km im kartesischen Koordinatensystem.

Positionsgenauigkeit

Die Positionsangabe der hier verwendeten, älteren, Smartphones (Gigaset GS180 und TP-Link/Neffos C5A) ist recht gut. Sie lässt allerdings nicht nachträglich darauf schließen, ob man auf dem Radweg oder daneben auf der Fahrbahn gefahren ist. Sie ist zumindest besser als die derzeitig verwendeten GPS-Sensoren (GY-NEO6MV2) in den Open-Bike-Sensoren (OBS, openbikesensor.org). Ob hier neuere Smartphones mit Galileo, GLONASS ... besser sind? Das wäre noch herauszufinden.

Hier wären einige Hintergärten mit Zäunen oder Hanglagen mit Büschen und Bäumen im Weg gewesen. Die Abweichung von hier teilweise über 20 m ist leider zu groß für eine automatische Unterscheidung Radweg oder Fahrbahn. Bis auf die magentafarbene Fahrt (Bild 4, TS6Gr) sind die Fahrten mit dem Neffos durchgeführt. Aber auch laut GS180 (rot in Bild 3) wären es Hausdurchfahrten gewesen.

Zeitliche Auflösung

Die zeitliche Auflösung des GPS beträgt ca. 1 Hz, die der Beschleunigung ca. 100 Hz. Für die einzelnen Beschleunigungspunkte werden die GPS-Punkte linear interpoliert. Damit hat man alle paar Zentimeter Beschleunigungswerte und verliert den »Kleinkram« nicht. Alternativ könnte man auf mittig zwischen GPS-Punkte gelegte Fenster die Extremwerte filtern und die Daten reduzieren.

Für ein Frequenzspektrum/Spektralanalyse der Beschleunigung ist eine Abtastungsrate von 200 Hz zu niedrig, bei 500 Hz (Samsung S21) ist man in einem Bereich, wo es schon interessant wird und der Autor wohl auf Python umsteigen muss ;-)

Beim Vergleich der Ausgaben von phyphox ist aufgefallen, dass die Aufzeichnungsraten teilweise deutlich unterschiedlich sind (Tabelle 1).

Die Datenrate sollte man beim Auswerten von längeren Touren berücksichtigen. Einige Programme (z. B. GPX Viewer) haben mit der GPX-Datei von 100 Hz und ca. 30 Minuten Mühe.

Die Lenkerhalterung ist bewusst steif ausgeführt. Sie ist mit dem PrusaSlicer erstellt und gut abwandel- und druckbar (Handlebar-Mount for Neffos C5A).

Die Ausrichtung erfolgt waagerecht. Es würde sich aber auch im Code ein Herausrechnen aus den Beschleunigungen nach einer Einschwingphase anbieten. Dann ließe sich das Smartphone ggf. besser lesbar ausrichten. Nur stehen die meisten Räder mit »undefiniert« eingeschlagenem Lenker auf dem Ständer und haben dann entsprechend in allen drei Raumrichtungen einen zufälligen »Startwert«. So ist eine gezielt waagerechte Montage und Auswertung nur von z (senkrecht zum Bildschirm) die »simplere/idiotensichere« Lösung.

Datenauswertung

Der awk-Code erkennt automatisch das Format des Exports von phyphox:
Tab, Komma oder Semikolon als Trennzeichen.
Punkt oder Komma als Dezimaltrenner.

Daraus werden mehrere Dateien erzeugt:

• Interpol.txt
  Eine einfache Textdatei (für z. B. gnuplot). Mit den ermittelten GPS-Positionen (siehe Unterschied der Abtastraten in Tabelle 1) werden für die Beschleunigungswerte dazwischen linear interpolierte Positionen errechnet:
  #time; lat; long; v; a_z
#[s]; [Grad]; [Grad]; [km/h]; [g]
#1; 2; 3; 4; 5
25,27; 52,123; 5,123; 11,82; -0,04
• Interpol.gpx
  Datei im XML-Format für diverse GPX Viewer. Die Beschleunigung wird als Höhe kodiert. Es wäre sicherlich auch möglich, das im XML-Code anders zu kodieren, nur können die mir bekannten GPX Viewer (siehe unten) neben Geschwindigkeit nur Höhen anzeigen.
• LevelCrossing.dat
  ist eine Textdatei. Hier werden die Beschleunigungen klassifiziert nach Spitzenwerten zwischen »Nulldurchgängen« und aufsummiert. Diese Darstellung wird häufig für Belastungsspektren im Maschinenbau verwendet.
  #generated with gawk -f LevelCrossing_v03.awk -v deadb=0.3 -v nle=60

#level; n; n/n_max
#1; 2; 3
-4,262; 5; 0,00405

Die Beschleunigung wird nur für z (senkrecht zum Display) ausgewertet. Da das hier verwendete Smartphone (Neffos C5A) die Erdbeschleunigung g nicht abzieht, erledigt das der Code und rechnet gleich noch von m/s² nach Vielfachen von g = 9,81 m/s² um. Als Optionen können

• -v deadb=Wert, hier 0,3 g. Beschleunigungen mit einem Betrag kleiner als dieser Wert werden nicht gezählt
• -v nle=Wert, hier 60. Anzahl der »Körbchen«, in die die Häufigkeit der Werte zwischen maximaler und minimaler Beschleunigung gezählt werden

übergeben werden.

Anmerkung: Im Arbeitsschutz wird die Beschleunigung in m/s² angegeben. In meinem Berufsumfeld eher in Vielfachem von g.

Was noch fehlt: Erzeugung eines Links oder Shellscriptes, um aus OpenStreetMap gleich das png für den Track herunterzuladen, um es in gnuplot hinter den Track zu legen.

Der aktuelle awk-Code: interpol-gpx-v02.awk

Die gnuplot-Beispieldateien: plot-beschleunigung.gnu; plot-geschwindigkeit.gnu

Ergänzungswünsche

Es gibt so einige Punkte, die die Software noch erledigen oder auswerten könnte. So zum Beispiel eine automatische Erkennung des Verkehrsweges (Radweg, Fahrbahn, über den Kantstein heruntergefahren). Vielleicht lässt sich das aus den Kartendaten von OpenStreetMap extrahieren. Ob Radwege existieren, ist häufig schon kodiert und wird beim OBS-Portal verwendet. Allerdings ist hier die Ortsgenauigkeit (siehe oben) derzeit der Spielverderber.

Kartendarstellung

Bisher ist mir kein Programm für Linux bekannt, das gut konfigurierbar die Beschleunigung in der Karte darstellen kann. Bisher getestet wurden:

• GPXSee (hat auch mit längeren und mehreren Aufzeichnungen kein Problem, ist aber im Hineinzoomen limitiert)
• GPX Viewer
• gpx studio

Thomas Zastrow hat mit seiner Herangehensweise anscheinend eine recht gute und konfigurierbare Lösung gefunden. Zumindest, wenn man sich in python einarbeitet.

Statistik/Level Crossing

Bei einer entsprechenden Filterung ist in der Kartendarstellung (Bild 1) schon recht gut zu sehen: Radwege sind i. A. mit deutlich höheren Erschütterungen als Fahrbahnfahrten versehen. Und selbst Fahrbahnen weisen deutlich unterschiedliche Qualitäten auf. Messwerte unter 0,5 g sind bei mir kaum vorhanden. Selbst »nigelnagelneue« gute Radrouten sind mit einem Hintergrundrauschen von ca. 0,5 g belegt.

Einflüsse des Fahrrads

Um Aussagen über die Einflüsse des Fahrrads auf die Messungen machen zu können, werden erste, orientierende, Vergleichsmessungen durchgeführt mit:

• zwei Fahrrädern
  • J: ein voll gefedertes R+M Delite mit Magura-Rond-Federgabel
  • T: ungefedertes Patria Terra
• unterschiedlichen Reifen
  • S: Continental Spike Claw 120 und
  • C: Continental Contact Speed 559 × 50
• unterschiedlichen Luftdrücken
  • 3 bar
  • 4 bar
  • 5 bar
  • 6 bar
• Smartphones
  • G: Gigaset GS180
  • N: Neffos C5A
• leicht unterschiedlichen Geschwindigkeiten (20–35 km/h)
  • l: links um den Block
  • r: rechts um den Block

Die Teststrecke ist mit Anteilen von Asphalt, unterschiedlich abgesenkten Bordsteinen und Schachtdeckeln, Granitpflaster, 50-cm-Betonplatten, unbefestigter Oberfläche versehen (Bild 6).

Diese Unterschiede zeigen keinen wesentlichen Einfluss auf die Messergebnisse. Lediglich die »extrem« starken Ausschläge waren bei dem voll gefederten Rad reduziert.

Bei später durchgeführten Fahrten mit dem ungefederten Terra mit Continental Contact Speed und 2, 3, 4 und 6 bar waren nur bei 2 bar die Unterschiede zu sehen. Allerdings wird dann der Reifen besonders in den Kurven so weich, dass ein sehr unangenehmes Fahrverhalten vorliegt.

Diese Fragestellung ist notwendig, da es diverse Smartphone-Apps zur Messung von IRI (International roughness index) für Kfz gibt. Dort ist die gefederte Masse deutlich größer und die Federungskonzepte können sehr unterschiedlich sein.

Ausblick

Für die Zukunft ist mein Ziel, die Daten von phyphox in Wegekategorien (Fahrbahn/Radweg) aufzuteilen und danach dann eine Statistik zu erzeugen. Damit kann dann Verwaltungen Handlungsbedarf aufgezeigt werden. Vor allem, dass benutzungspflichtige Radwege die Gesundheit der Radfahrer mehr strapazieren als die meist besser unterhaltenen Fahrbahnen (Ausnahmen bestätigen die Regel). Hier können auch die beruflichen Bedingungen der Fahrradkuriere und Fahrrad nutzenden Lieferdienste Druck verschaffen.

Ist das automatisierbar? Bisher kaum, da bei den meisten (GPS-)Aufzeichnungen die Genauigkeit mit einem automatischen Abgleich von z. B. OpenStreetMap (OSM) nicht ausreicht. Derzeit bleibt es dem Nutzer überlassen, sich bei der Datenauswertung zu erinnern: »War ich in diesem Abschnitt auf dem Radweg oder auf der Fahrbahn unterwegs?«

Könnte man daraus ein Citizen-Science-Projekt machen, vergleichbar zum OBS? Könnte man eventuell das gleiche Portal oder den gleichen Ansatz nutzen? Damit wäre auch gleich eine statistische Absicherung durch mehrere Nutzer auf gleichen Strecken erreichbar.

Ist eine Ausgabe in Richtung Pavement condition index (PCI) oder International roughness index (IRI) möglich? Cyface bietet die Umrechnung in IRI angelehnt an. Es gibt anscheinend schon einige Apps für Smartphones für IRI und PCI zur Bestimmung im Kfz.