Leistungsmesser für Fahrräder sind für gewöhnlich recht teuer. Auf dem Markt sind verschiedene Systeme üblich, zum einen welche, die in den Pedalen montiert werden - andere werden dagegen an der Kurbel montiert oder in die Kurbelwelle selbst eingebracht. Für mich als eigentlich nur sporadisch radelnde Person lohnt sich die Anschaffung also eher nicht. Das Funktionsprinzip ist schnell klar: Dehnmessstreifen messen Verformungen am Material und wandeln die durch die Tritte entstehenden Längenänderungen in einen Wert für das Drehmoment und somit die Leistung um. Einfache Dehnmessstreifen sind schon für wenige Euro im Internet zu haben, genauso die dazugehörige Auswerteelektronik. Das schreit nach DIY!
Hardware-Aufbau
Erste Tests zum generellen Umgang mit Dehnmessstreifen führte ich an meinem Tretroller durch. Zwar kann ich hier keine Leistungen messen, aber trotzdem den Umgang mit der Messtechnik üben. Großer Vorteil hierbei ist der Mangel an beweglichen Teilen: Es war hier völlig egal, wie klobig die Elektronik ist - irgendwie lässt die sich dann schon mit Klebeband am Tretroller-Lenker befestigen. Mit jedem Tritt in die Pedale verbiegt sich der Kurbelarm ein kleines Stück. Ein darauf festgeklebter Dehnmessstreifen kann solche Längenänderungen über serpentinenartig verlegte Leiterbahnen in eine Widerstandsänderung umwandeln. Bringt man zwei Sensoren an, einen auf der Ober- und einen auf der Unterseite der Kurbel, so wird bei einem Tritt der obere gestreckt und der untere gestaucht, die Widerstände der Messstreifen größer bzw. kleiner.
Abb. 1: aufgeklebte Dehnmessstreifen auf Kurbel-Arm
Über eine Halbbrücke kann diese Widerstandsänderung in eine Spannungsdifferenz umgesetzt werden. Diese wird wiederum von einem für diesen Zweck konstruierten Analog-Digital-Konverter (HX711) in einen digitalen Messwert umgewandelt werden. Der ADC wurde eigentlich für Waagen entwickelt - aber ob der Dehnmessstreifen jetzt ein Gewicht auf einer Waagschale erfasst oder eine auf ein Pedal wirkende Kraft… Für die weitere Verarbeitung der Messwerte fiel die Wahl vorerst auf einen ESP8266. Ein kleinerer Microcontroller hätte es auch getan. Über einen mit Lötfahnen versehenen SD-zu-micro-SD-Adapter speichert der ESP die Messwerte direkt in eine CSV-Datei auf der SD-Karte. Die Energieversorgung erfolgt über die Elektronik eines zerlegten Handwärmers. Der Akku ist recht flach und hat bereits die nötige Ladeelektronik sowie einen kleinen Boost-Konverter mit an Bord, der gut 4V liefert - genug für Prozessor und ADC.
Abb. 2: Struktureller Aufbau von links nach rechts: Buchsenleiste zu den Dehnmessstreifen, Akku (silberfarben), ADC (grüne Platine), ESP8266 (blaue Platine), Laderegler (grüne Platine), SD-Karten-Halter (unter den Laderegler geklebt)
Auf dem Fahrrad ist das ganze etwas enger als am Tretroller: Da sich ja alles mit den Pedalen mitdreht, sind zum Beispiel keine Kabel-Verbindungen zum Rahmen möglich. Der Platz ist außerdem auf den Raum zwischen Kurbel und Fahrradrahmen beschränkt - alles andere würde beim Pedalieren stören. Die Profi-Lösungen schaffen es die Technik so zu minimieren, dass sie in den normalen Formfaktor eines Kurbelarms passen. Beim Eigenbau geht das nicht so gut - alleine die Akku-Technik ist größer und der Microcontroller “überdimensioniert”. Ein Freund zeichnete netterweise ein Gehäuse für die Komponenten, das über den 3D-Drucker dann Gestalt annahm. Die Form ist an die Kurbel angeglichen, eine Kante schmiegt sich direkt an das Metall an.
Abb. 3: Computermodell des Sensor-Gehäuses
Bei der Montage fiel allerdings auf, dass das Gehäuse etwas zu klein ausfiel. Für die ersten Tests ist das aber nicht schlimm, es war sowieso absehbar, dass eine zweite Revision dieses Modells nötig sein wird: Mit einem Seitenschneider war die hintere Rückwand schnell entfernt und mit dem Heißluftgerät sowie einem Teppichmesse die mittlere Ausbuchtung für die Schraubmontage herausgeschnitten.
Abb. 4: Montage der Messtechnik an der Kurbel. Rechts neben dem schwarzen Klett-Kabelbinder ist einer der zwei aufgeklebten Dehnmessstreifen zu erkennen. Rechts ragen Teile der Platine heraus, die Seitenwand
Software
Eine erste Testfahrt führte mich einmal um den Block. Die dabei gemessenen Daten waren recht vielversprechend: Den ersten Quellcode des Datenloggers konnte ich aus einem anderen Projekt in leicht modifizierter Form übernehmen. Über ein Python-“Ingest-Skript” wurden die Daten in eine Influx-Datenbank importiert und über einen simplen Grafana-Plot visualisiert (Abb. 5):
Abb. 5: Ausschnitt der Messwerte bei der ersten Testfahrt.
Sind denn die Testwerte plausibel? Zeitlich gesehen passen die Messwerte schonmal gut: Die Fahrtdauer entspricht grob der Dauer der Aufzeichnung, Abweichungen kommen von Unterschieden beim Aufzeichnungsstart. Auch wenn man sich den Signalverlauf über die Zeit ansieht sind gut verschiedene Phasen auszumachen, darunter im hinteren Bereich mehrere Momente mit konstanten Werten. Das sind die Haltephasen als ich mit dem Rad an einer Ampel stand. Hier ist auch gut zu erkennen, dass ich einmal den Fuß ganz vom pedal nahm, nach ein paar Tritten danach jedoch den Fuß auf dem Pedal aufsetzte. Dort ist der Ausschlag dann nicht auf “null” sondern auf einer mittleren Auslenkung.
Abb. 6: mikroskopischer Ausschnitt von mehreren Pedal-Bewegungen.
Schaut man sich die Daten genauer an (Abb. 6) ist ein grober Sinus-Verlauf des Signals zu erkennen. Da ich bei der Montage nicht darauf achtete, auf dem Breakout-Board des ADC-Wandlers eine Lötstelle zur Samplefrequenz-Änderung umzustellen ist die Samplerate nur bei 10-11 Hz. Der Sensor könnte ansonsten auch mit bis zu 80 Hz Messwerte liefern.
Vorerst wird aber mit Werten dieser Samplerate gearbeitet. Ziel ist ja die getretene Leistung, das lässt sich grob mit Schulphysik nachvollziehen: P = E/t und E = F * s. Energie ist also Kraft mal Strecke, die Strecke ist bei einer vollen Kurbelumdrehung π*d. Unbekannt ist aber nach wie vor die Kraft F. Diese lässt sich aus dem Ausschlag der Dehnmessstreifen ableiten. Hierfür treffe ich die Annahme, dass sich die Messstreifen in meinem Nutzungsbereich linear verhalten. Deshalb reichen für die Umskalierung zwei Messwerte. Zum einen Wähle ich den “Leerlauf” des Sensors, also ein unbelastetes Pedal. Für einen zweiten Messwert unter Belastung verwende ich einen Wasserkanister, den ich so gut wie möglich auf dem Pedal bei angezogener Bremse balancierte. Aus diesen beiden Werten und den zugehörigen Gewichten (0 Newton und 61 Newton) ergibt sich dann die wirkende Kraft. Integriert man diese skalierte Welle, so hat man in der Theorie die Energie dieses einzelnen Trittes bestimmt.
Schön wär’s, wenn das auch der Praxis entspräche. Leider ist das Verfahren rechenintensiv (anstelle eines normalen Integrals verwende ich die simpson-integration die - anders als das Sehnentrapezverfahren - bei den gegebenen Halbwellen nicht notorisch die Fläche unterschätzt) und kann nur schwer mit der Drift des Signals umgehen, da ja der Nullwert konstant vorgegeben ist. Deshalb behelfe ich mich mit einer einfacheren Methode: Jede Halbwelle wird gemittelt und dieser Kraft-Mittelwert durch die verstrichene Zeit dividiert. Das ergibt automatisch eine Leistungsangabe zu diesem Zeitpunkt. Doch wie bestimme ich die Dauer einer solchen Welle? Anfangs stand hier eine Fourier-Transformation im Raum - damit lässt sich die Trittfrequenz tatsächlich bestimmen. Leider ist die Frequenzauflösung abhängig von der Anzahl der Punkte in der DFT. Je mehr Punkte gewählt werden, desto genauer wird die Auflösung und umgekehrt. Wähle ich allerdings einen größeren Ausschnitt der Messdaten wie er für eine ausreichende Frequenz-Genauigkeit nötig wäre, wird der betrachtete Zeitraum schnell länger als eine Minute. Das ist unattraktiv, besonders, wenn man kurze Sprintphasen o.ä. nicht “ausmitteln” möchte.
Nach ein paar Versuchen stellt sich dann eine sehr einfache Methode heraus: Die Zeit zwischen zwei Signal-Dips entspricht genau einer Pedalumdrehung. Fällt das Signal über diese Schwelle beginnt ein Tritt, fällt das Signal erneut, beginnt der nächste Tritt, die Zeit dazwischen ergibt im Kehrwert die Trittfrequenz. Der Schwellwert wird aktuell über ein global arbeitendes Verfahren festgelegt: Ein Algorithmus bestimmt für eine Serie an Schwellwerten die Anzahl der Tritte. Ist der Schwellwert zu hoch bzw. zu tief angesetzt werden keine Schritte erkannt, zum gewünschten Schwellwert werden immer mehr korrekte Tritter erkannt. Bestätigung für die Stabilität dieses Verfahrens beweist ein Plot der erkannten Trittanzahlen: Der errechnete Schwellwert stellt sich ein in einem Plateau ein, das heißt, der Algorithmus kann auch gewisse Schwankungen kompensieren.
Abb. 7: Berechnung der Tritt-Anzahlen im Track in Abhängigkeit des Schwellwertes (blau) und festgelegtem Maximum (grün)
Nun sind beide für die Leistungsberechnung nötigen Komponenten beisammen - die zeitliche Analyse kann beginnen. Zur Orientierung dient die automatische Berechnung der Sport-Plattform Strava. Da deren Daten jedoch ausschließlich basierend auf den GPS-Daten berechnet werden, sollte diesen auch nicht zu viel Gewicht zugemessen werden. An die Genauigkeit der Profigeräte von ca. +/- 1,5% Abweichung kann auch die Bastellösung nicht heranreichen. Nichts desto trotz sehen die Ergebnisse bis jetzt vielversprechend aus:
Abb. 8: Vergleich der eigenen Leistungsberechnungen (blau) mit den Daten von Strava (orange)
Im Allgemeinen liegen die zwei Plots nicht gerade aufeinander - aber gerade die Pause/Rollphasen passen gut zusammen sowie die insgesamt berechnete Leistung stimmt auch bis auf wenige Watt überein. Seriösere Aussagen lassen sich allerdings erst nach mehreren weiteren Testfahrten treffen.
Hier machen sich die bisher ungelösten Schwierigkeiten bemerkbar: Aktuell besteht kein Automatismus, bestehende Aufzeichnungsgeräte mit den aktuell erfassten Werten zu korellieren. Aktuell legt der Microcontroller nach jedem Startvorgang eine neue Datei an, dessen Zeitstempell beginnen aber jedes Mal bei Null. Startet man nicht gleichzeitig eine Aufzeichnung z.B. auf dem Handy, müssen die Daten nachträglich von Hand korelliert werden. Schöner wäre hier zum Beispiel die Übertragung der Werte über Bluetooth oder ANT+, wobei vor allem für letzteres ein anderes Funkmodul verwendet werden müsste. Alternativ würde sich auch die Zusammenarbeit mit einem weiteren Microcontroller eignen, zum Beispiel am Lenker. Dort wäre dann auch Platz für ein kleines Display sowie einen GPS- oder Uhrzeit/DCF77-Empfänger, der sich um die Datenaufzeichnung kümmern könnte.
We’ll see.