Kann ich die genauen Statistikwerte aus der Tabelle heraus erzeugen?
Ja, müsste gehen. Da werden schließlich nur die einzelnen Datenwerte aufsummiert (
siehe hier im Code; geht, da konstanter Zeitschritt von 1 s) und danach die Prozente berechnet.
Dort könnte man auch die Gänge i und das Kettenblatt mit einbeziehen... , das heißt der Nutzer Deines Programms wählt noch KB-Zahnanzahl und Masse aus und gegebenfalls welche Kassette /welches der bevorzugte Gang/ das bevorzugte Ubersetzungsverhätnis ist .. wenn schon denn schon!!
Erhöht das denn die Genauigkeit? Oder fügt das unnötige Komplexität hinzu?
Das Kettenblatt dreht sich ja ungefähr immer mit der gleichen Trittfrequenz, d.h. die größte Beschleunigung gibt es beim Anfahren. Und die Kassette dreht sich immer mit der Geschwindigkeit des Hinterrads, d.h. die kann man in die Rotationsenergie des Hinterrads mit einrechnen.
Tipp : bei den relevanten rotierenden Massen immer die Außenmassen zählen also, Felge + Reifen / Schlauch... - ich habe keine Ahnung, was sowas - Felge, Reifen,.. - wiegt.. ?? Insbesondere die Felgen.... 3Kg ?!
Bei den Vorderrädern weiß ich, dass sie etwas über 1 kg liegen. Mein Hinterrad habe ich nicht gewogen, aber laut Angaben von Ginkgo scheint es nicht nennenswert schwerer zu sein, weil z.B. die schwere Trommelbremsnabe wegfällt.
Bei den Rädern ist es eben einfach; die drehen sich außen immer mit Fahrgeschwindigkeit. Wenn deren Masse komplett an den äußeren Rändern wäre, dann entspricht die Rotationsenergie genau der linearen Bewegungsenergie, und sie beschleunigen gemeinsam mit dem ganzen Fahrzeug und ihre Rotationsenergie steht zusammen mit der Bewegungsenergie zur Verfügung, um z.B. bergauf zu rollen.
Da die Masse der Räder nicht ganz außen ist, ist das Trägheitsmoment etwas geringer. Deshalb würde ich pauschal die Masse etwas geringer ansetzen (daher die 3 kg, was weniger als das reale Gewicht ist, aber vermutlich immer noch etwas zu hoch).
Bei anderen rotierenden Komponenten ist dieser Zusammenhang nicht so einfach, und deren Rotationsenergie ist auch nicht so einfach nutzbar (z.B. bergauf). D.h. das würde ich eher pauschal den Antriebsverlusten zuschlagen.
Wenn die v-Iteration solche Probleme macht - ihr rechnet doch eh abschnittsweise, dann wäre es doch relativ leicht, einen kleinen Trick aus der Spieleprogrammierung anzuwenden und für jeden Gefälle+Gegenwind(oder was immer ihr sonst noch an äußeren Einflüssen einrechnet)-Abschnitt ein kleines numerisches Array vorzuberechnen P=f(v), meinetwegen auch im erwarteten Zielbereich ±25% und als v=f(P) zurückzuinterpolieren,
das Array muss man relativ selten berechnen, und die Interpolation, auch wenn sie quadratisch ist, geht schnell und liefert 1 Ergebnis!
Aber das geht natürlich nur für jeden gleichförmig beschleunigten Abschnitt...
Zuerst muss ich einmal verstehen, warum diese Probleme auftreten und ob das in der Praxis wirklich ein Problem ist, statt prophylaktisch dort Aufwand reinzustecken.
Und ich glaube, in der Spieleprogrammierung hat man das früher gemacht, als Rechenleistung knapp war – heute dürfte es schneller sein, Dinge einfach zu berechnen; gerade auch, weil die Formeln der Fahrtwiderstände ja recht simpel sind, da ist eine Interpolation kaum einfacher.
Was vielleicht helfen würde: in den Iterationen mitzunotieren, wie sich die Leistung mit der Geschwindigkeit ändert (z.B. bei Steigung deutlich stärker). Es geht ja darum, bei großem Leistungsdefizit die Leistung stark anzupassen, aber eben nicht mit festen (= vom Leistungsdefizit abhängigen) Geschwindigkeitsschritten, sondern abhängig davon, wie stark die Geschwindigkeit momentan die Leistung verändert.
