Super Arbeit @Christoph Moder ,

Du trägst mit Deinen Projekten immer wieder dazu bei, Licht ins Dunkel zu bringen.

Jetzt ärgert es mir doppelt, dass wir auch dieses Jahr keine Abendlichen Gespräche auf Italiens Campingplätzen führen können.

Zwei Fragen gingen mir, während der Lektüre, durch den Kopf. Ich hoffe, daß ich das nicht überlesen übersehen habe.


Ist der Einfluß der Außentemperatur für Roll und Luftwiderstand so klein, daß er vernachlässigt werden kann?


Wie ist das mit Gegenwind aus versiedenen Richtungen, da entsteht je nach VM Modell ein mehr oder weniger starker Segeleffekt, der Antriebsleistung übernimmt.

Vielen Dank für Deine Arbeit.
 
Ist der Einfluß der Außentemperatur für Roll und Luftwiderstand so klein, daß er vernachlässigt werden kann?
Nein:
  • Du kannst sie schon einstellen; Parameter temp.
  • Mit den Voreinstellungen beträgt die Geschwindigkeit nach 3 km 51.7 km/h; wenn man die Temperatur von 20°C auf 0°C ändert, wird nur noch 50.9 km/h erreicht.
  • Das ist aber nur der Einfluss der Luftdichte, also Luftwiderstand.
  • Für den Rollwiderstand kenne ich keine Formel, und dieser Einfluss ist deutlich größer, und nach meiner Erfahrung auch nichtlinear – während er im Frühling/Herbst nicht so viel anders ist, steigt er bei winterlichen Temperaturen stark an. Und das hängt auch noch vom jeweiligen Reifen ab.
  • EDIT: D.h. für den Rollwiderstand müsstest du den Parameter cR entsprechend anpassen. Mangels Formel nur nach Erfahrungswerten.
Wie ist das mit Gegenwind aus versiedenen Richtungen, da entsteht je nach VM Modell ein mehr oder weniger starker Segeleffekt, der Antriebsleistung übernimmt.
Auch dafür kenne ich keine Formel. Es gab nur für den Milan mal eine Messung; und ich habe keine Ahnung, inwiefern das auf andere Velomobile übertragbar ist.

Wenn man weiß, wie viel das ausmacht, könnte man das in einen virtuellen Rückenwind umrechnen, und den kann man ja problemlos einstellen.
 
Zuletzt bearbeitet:
Vorschlag in aller Kürze: Wir messen cr in Abhängigkeit von Temperatur, Reifendruck und Reifentyp und Strassenbelag und tabellieren das Ganze, dann kann das Programm cr einlesen/berücksichtigen. Die Bestimmung von cr erfolgt nach einem vordefinierten Verfahren ( Rolltest mit niedriger Geschwindigkeit) .. dauert bestimmt ein paar Jahre, aber dann haben wir was Konkretes...
 
Was ich gehört habe wirkt sich subjektiv die Temperatur auf cr stark aus... hat da jemand vielleicht schon Tabellenwerte? -die Temperaturabhängigkeit der Luftdichte spielt wie Christoph sagte da eine untergeordnete Rolle..
 
Zuletzt bearbeitet:
Hm, habe ich mit Firefox auf meinem Android-Tablet probiert - da tut sich offenbar mal wieder nichts :(
Vermutlich weil dort kein Browser eine Javascript-Konsole bietet. (Ist eben eine sehr bequeme Methode, um Text rauszuschreiben.)

Du könntest mal den Android Web Inspector installieren (gibt es auch im Play Store), dann die Seite aufrufen, CSV einschalten, und dann im Menü „XHR Logs“ aufrufen.

Falls ein echter Bedarf da ist, könnte ich auch ein neues Fenster aufmachen und da rein schreiben.
 
die Temperaturabhängigkeit der Luftdichte spielt wie Christoph sagte da eine untergeordnete Rolle..
Na, untergeordnet ist da nichts:
Mit den Voreinstellungen beträgt die Geschwindigkeit nach 3 km 51.7 km/h; wenn man die Temperatur von 20°C auf 0°C ändert, wird nur noch 50.9 km/h erreicht.
Da die Leistung mit dritter Potenz eingeht, bedeuten diese 1,6% schneller mit Epsilontik 3*1,6 = 4,8% mehr Leistung !
 
@labella-baron : aah, danke für Deinen Hinweis! okok... alles relativ ! :) - Ich hatte 0.7km/h für nicht sooo relevant angesehen... Jedenfalls, wenn sich der wichtige cr-Wert vergleichsweise eher stärker durch die Temperatur ändert... Ich habe ja hoffentlich meine Version mit 2 Velos zeitnah fertig, so dass man den direkten Vergleich auch dazu schneller/bequemer einschätzen kann... Ich habe vor allem den cw- bzw. cwa-Wert, den cr- und den crv-Wert als die entscheidenden Faktoren wahrgenommen, aber man muss natürlich auch die Luftdichte mit reinnehmen. Hier spielt, soweit ich mich erinnere insbesondere auch die Luftfeuchte mit rein.. Das ist ( in meinem Modell ) noch nicht berücksichtigt, in Christophs glaube ich, auch nicht ?! Aber sowas kann man nachträglich leicht miteinbauen - alles eine Frage der Prioritäten..

Schöne Grüße,

Schaltnix

PS : Dritte Potenz : Du meinst P = faktor * v^3 - da geht die Leistung mit der dritten Wurzel ein und rho steckt linear im Faktor.. Ansonsten sieht man es ja bei Kreuzotter.de : v hängt von rho nicht sooo dramatisch ab bzw. es hält sich in Grenzen... Ich mache mal demnächst Plots dazu...
 
Habe noch extreme Hantierungsprobleme.
Dennoch die Frage:
Screenshot_20210502-180820_Firefox.jpg
Wie kommt es zu der blauen "Geschwindigkeitsfläche" ab 0,5km ?
 
PS : Dritte Potenz : Du meinst P = faktor * v^3 - da geht die Leistung mit der dritten Wurzel ein und rho steckt linear im Faktor.. Ansonsten sieht man es ja bei Kreuzotter.de : v hängt von rho nicht sooo dramatisch ab bzw. es hält sich in Grenzen... Ich mache mal demnächst Plots dazu...
Gemeint ist: Bei kaltem Wetter ist man bei gleicher Leistung langsamer; und um die Geschwindigkeit wieder auf den ursprünglichen Wert anzuheben, steigt die Leistung für den Luftwiderstand kubisch mit der Geschwindigkeit.
Wie kommt es zu der blauen "Geschwindigkeitsfläche" ab 0,5km ?
Gute Frage. Ich denke, das ist keine Fläche, sondern eine Kurve, die nach unten und oben zappelt. Also ein numerischer Fehler. Da könne man mal reinzoomen und schauen. Wahrscheinlich wird da die Geschwindigkeit zwischen den Iterationen zu stark korrigiert.
 
Kurze Zwischenfrage zur Bedienung:
Ich kann so Punkte setzen, aber das Löschen ist schwierig. Manchmal klappt es durch noch mal drauf klicken. Meist aber nicht?! Gibt es einen Trick?
 
Ich kann so Punkte setzen, aber das Löschen ist schwierig. Manchmal klappt es durch noch mal drauf klicken. Meist aber nicht?! Gibt es einen Trick?
Ja, das ist schwierig. Ich muss noch herausfinden warum – wahrscheinlich werden die richtigen Punkte nur dann gefunden, wenn man exakt am richtigen Punkt ist, und wenn man die ganzen anderen Datensätze ausblendet, scheint es etwas besser zu gehen.

Das Plugin, das die Verschiebe-Funktionalität hinzufügt, hat keine Möglichkeit, Punkte hinzuzufügen und zu löschen. Entsprechend habe ich das selber dazu gebastelt; und die Funktionen zum Herausfinden, welche Datensätze in der Nähe sind, sind schlecht dokumentiert. Ich muss rausfinden, was da genau passiert.
 
Vielleicht kannst du noch die Statistikzahlen etwas erläutern:
Screenshot_20210502-213632_Firefox.jpg
Rot sind Input-Werte und blau Output. Was sind wieder die Werte darunter? Warum sind sie ganz anders als die blauen Werte? Wieso taucht die Beschleunigung (P_accel) auf, aber keine Verzögerung? Und in/out ist 146% obwohl als Antriebsverluste nur 8% voreingestellt sind!
 
Gute Frage. Ich denke, das ist keine Fläche, sondern eine Kurve, die nach unten und oben zappelt. Also ein numerischer Fehler. Da könne man mal reinzoomen und schauen. Wahrscheinlich wird da die Geschwindigkeit zwischen den Iterationen zu stark korrigiert.
Ja, dann sieht man es deutlich:
Vielen Dank!

Mir ist auch klar geworden, warum das so ist:
  • Die Geschwindigkeit muss in der Iteration ausreichend fein korrigiert werden.
  • Andererseits soll das Skript nicht zu lange laufen.
  • Daher hatte ich die Schrittweite der Geschwindigkeitskorrekturen abhängig vom Leistungsbilanzdefizit gemacht: bei großem Leistungsdefizit wird die Geschwindigkeit stark angepasst; wenn man schon nahe an der richtigen Lösung ist, nur noch wenig.
  • Das funktioniert aber nicht bei starker Steigung, weil dort die benötigte Leistung riesig ist (und darum auch der Fehler, wenn man von der vorherigen groben Geschwindigkeit ausgeht), die Geschwindigkeit selbst aber klein ist.
  • => Wenn man hier die Geschwindigkeit in großen Schritten korrigiert, trifft man den wahren Wert nicht, sondern schießt immer dran vorbei. Daher das Zickzack.
Jetzt muss ich mir noch überlegen & messen, wie eine sinnvolle Geschwindigkeitskorrektur aussehen könnte. Wo die Schritte nicht zu klein sind, das Ergebnis aber trotzdem konvergiert.
Rot sind Input-Werte und blau Output.
Richtig.
Was sind wieder die Werte darunter? Warum sind sie ganz anders als die blauen Werte? Wieso taucht die Beschleunigung (P_accel) auf, aber keine Verzögerung?
Das ist noch ein Relikt aus dem Powermeter-Diagramm. Es ist ebenfalls eine Output-Leistung, bezieht sich aber nur auf die Leistung während des Tretens:
  • Wenn man die Output-Leistung global betrachtet (blau), spielt die Beschleunigung keine Rolle, weil am Anfang und Ende der Tour ist die Geschwindigkeit 0, die Netto-Beschleunigung also auch. Die aufgebaute Bewegungsenergie wurde komplett verbraucht.
  • Wenn man aber nur die Phasen des Tretens und des Rollens betrachtet, dann ist das anders:
    • Während des Tretens beschleunigt man oder fährt bergauf.
    • Wenn man nicht tritt, fährt man entweder bergab oder wird langsamer.
    • Daher wird z.B. der Rollwiderstand zu einem Großteil während des Tretens erbracht, während die Phasen, in denen der Luftwiderstand besonders groß ist, vor allem schnelle Bergab-Passagen sind.
  • D.h. mich hat interessiert, wo die Leistung hingeht, während ich trete.
Ist also etwas kompliziert, und vielleicht für die Simulation, wo man eine konstante permanente Tretleistung hat, nicht so relevant.
Und in/out ist 146% obwohl als Antriebsverluste nur 8% voreingestellt sind!
Ja, das wirkt seltsam.

Letztendlich ist das auch noch ein Relikt aus dem Powermeter-Diagramm; dort hat man ja einerseits die gemessene Leistung, und andererseits die gemessene Geschwindigkeit und die daraus berechneten Leistungen. Da ist es sinnvoll, die beiden vergleichen zu können und – bis auf die Antriebsverluste – anzugleichen.

Aber hier in der Simulation ist alles berechnet. Daher ist vollkommen klar, dass die Werte gleich sein sollten, da sie aus den selben Zahlen stammen.

Warum das hier anscheinend nicht so ist, habe ich mir noch nicht genau überlegt. Vielleicht ein Ergebnis der zappelnden Geschwindigkeitskurve.
 
  • D.h. mich hat interessiert, wo die Leistung hingeht, während ich trete.
Ist also etwas kompliziert, und vielleicht für die Simulation, wo man eine konstante permanente Tretleistung hat, nicht so relevant.
Oh, da bin ich ja auf komplexe Zusammenhänge gestoßen.
Ja, das wirkt seltsam.

Letztendlich ist das auch noch ein Relikt aus dem Powermeter-Diagramm
Da habe ich jedoch inzwischen eine Hypothese, warum trotz nur 8% Antriebsverluste der Input so viel größer als der Output ist.
Damals habe ich ja mit der Aufzeichnung Paris-Brest getestet und nicht mit dem 3km-Zufallsbeispiel von mir.
DIe Strecke ist in einer anderen Dimension und die Gesamtenergie in einem Mega-Bereich.
Im Zufallsbeispiel ist die Endgeschwindigkeit 76,5km/h und nicht Null und es verbleibt jede Menge Bewegungsenergie.

Ich habe noch einen Screenshot von damals gefunden, wo jedoch auch ein wesentlich höherer Input war:
Screenshot_20200313-130246_Firefox.jpg
Ich meine jedoch ich hätte auch ein Beispiel gefunden, wo es umgekehrt war - muss nochmal suchen.
 
Ich habe noch einen Screenshot von damals gefunden, wo jedoch auch ein wesentlich höherer Input war:
Bei dem Powermeter-Diagramm ist es auch kein Wunder; wenn die Parameter nicht zu den gemessenen Leistungsdaten passen, dann passen die berechneten Ein- und Ausgabeleistungen nicht zusammen, weil in ersterer die gemessenen Leistungsdaten stecken, und letztere aus der Geschwindigkeit und dem Höhenprofil berechnet werden.

Aber das ist ja hier anders, hier im Simulator wird die Leistung nicht aus gemessener Geschwindigkeit berechnet, sondern alles aus der Tretleistung bzw. Höhenprofil. Darum sollte es da keine Abweichungen geben.
 
@Schaltnix und @Christoph Moder wenn ich euch zwei verschieden Aufzeichnungen von der selben Fahrt zusenden würde! Eine aufgezeichnet mit P2M und die Andere mit Garmin Vektor 3, dann könnt ihr mir doch sicherlich den Unterschied in der unabdingbaren vorhanden Abweichung ausgeben oder?

Könnt ihr auch die Kurven übereinanderlegen und darstellen?
 
Zurück
Oben Unten