GPS/Leistungsmesser-Daten als Diagramm (Luftwiderstand, Rollwiderstand, ...)

[labella-baron]

Gut so

Was kann jetzt noch die Ursache sein,

dass hier bei Drivetrain 7% in/out=107% ist und hier

104% ist?

 

[labella-baron]

104% ist?

Habe es gefunden: im ersten Fall hatte ich cdyn=0,07 verwendet - sorry.

 

[labella-baron]

Zudem wird die berechnete Geschwindigkeit nicht ausgehend von der gemessenen Geschwindigkeit variiert, sondern ausgehend von der vorherigen berechneten Geschwindigkeit – außer, es wurde gebremst; dann wird von der gemessenen Geschwindigkeit ausgegangen.

Bei 20,8km ist dies der Fall:

Bei 21,01km nicht:

Gibt es eine weitere Nebenbedingung?

 

[Christoph Moder]

Gibt es eine weitere Nebenbedingung?

Nein. Hier mal der Ausschnitt aus dem Code; anfangs wird calc_speed auf den Wert des vorigen Punkts gesetzt, falls die Bremsleistung 0 ist; ansonsten auf den Wert der gemessenen Geschwindigkeit. Dann werden in einer Schleife die Fahrwiderstände für diese Geschwindigkeit ausgerechnet, und der Unterschied (resid) zwischen Eingangs- und Ausgangsleistung berechnet. Je nachdem, ob dieser kleiner oder größer als 0 ist, wird die berechnete Geschwindigkeit um SPEED_INC == 0.1 km/h verändert.

 var calc_speed = (P_brake === 0 && i > 0 && get_val(SPEED_CALC, i-1, 0) != null) ? get_val(SPEED_CALC, i-1, 0) : get_val(SPEED, i, 0);
                var resid = Infinity, prev_resid;
                var SPEED_INC = 0.1;

                // compute difference between input and output power
                do {
                        // store previous values
                        prev_resid = resid;
                        prev_calc_speed = calc_speed;

                        // compute output power from current calculated speed
                        [P_roll, P_air, P_up, P_down, P_accel, P_decel] = compute_power(calc_speed, i > 0 ? get_val(SPEED_CALC, i-1, calc_speed) : calc_speed, i);

                        // compute output power sum
                        P_out = P_roll + P_air + P_up + P_accel;

                        // compute input power sum: muscle (minus drivetrain losses), downhill, deceleration
                        P_in = get_in_val(IN_MUSCLE, i, 0) * (1 - params['dtr'] / 100) + P_down + P_decel;

                        // difference between input and output power
                        resid = P_in - P_out;

                        // increase or decrease calculated speed
                        calc_speed += resid > 0 ? +SPEED_INC : -SPEED_INC;

                // continue until residual becomes larger again
                } while (Math.abs(resid) < Math.abs(prev_resid));

Nun der Vergleich zwischen meinem Solver-Fit vor drei Jahren:

Am Anfang ist noch gute Übereinstimmung dem gerechneten Geschwindigkeitsverlauf der schwarzen Kurve mit der gemessenen blauen Kurve. Danach kommen immer wieder Bremsungen obwohl ich natürlich nicht gebremst habe. Auch die Maximalgeschwindigkeit von 75km/h nach ca. 340m wird nicht erreicht. Dort ist der waagrechte Übergang. In der Folge von ca. 0,45-1,8km werden immer wieder leichte Bremsungen angezeigt. Die Energie kommt hier ausschließlich durch die Geschwindigkeitsverminderung P_decel. Durch die ganzen "Bremsungen" ist die Endgeschwindigkeit natürlich niedriger.

Meine Interpretation: Man sieht abwechselnd irre Spitzen und Täler bei P_decel. Diese dürften genau im Sekundenabstand wechseln. Sie entstehen m.E. durchs interpolieren der Radumdrehungszeiten auf ganze Sekundenwerte.

Vielen Dank. Mir ist in den letzten Tagen da auch nichts Besseres eingefallen.


Insgesamt ergibt sich für mich folgendes Zwischenfazit:

• Grundsätzlich habe ich Vertrauen in die Rechnungen, weil da in letzter Zeit auch kein echter Bug aufgetaucht ist. Alles war immer richtig gerechnet (bzw. „wie beabsichtigt“, auch wenn das irreführend war).
• Bei den Rolltest-Daten gibt es noch offene Fragen; aber das könnte man nur mit einer höheren zeitlichen Auflösung klären, die aber nicht so ganz einfach zu implementieren ist.
• Für echte Leistungsmesser-Daten spielt das aber meiner Meinung nach keine Rolle, weil dort die Messdaten viel zu grob und ungenau sind. Daher sind die Beiträge von @labella-baron wertvoll für die Fehlersuche (= haben mich dazu gebracht, mir alles noch einmal genau anzuschauen und Erklärungen zu finden), aber für die Aussagekraft ist es relativ egal, ob man das letzte Watt erklären kann.
• Das Höhen- und Geschwindigkeitsprofil halte ich grundsätzlich für richtig, weil es dort keine großen Sprünge gibt. Trotzdem, eine winzige Abweichung führt bei Beschleunigungs- und Kletterarbeit (bzw. deren Gegenteilen) zu großen Abweichungen. Aber wie will man das feststellen, wenn keine erkennbaren Artefakte sichtbar sind?
• Generell haben wir eine zu schlechte Vorstellung von den Fehlern der Messdaten. Geschwindigkeit und Höhe kennt man ja so ungefähr von der Display-Anzeige während der Fahrt; daher weiß ich, dass die Geschwindigkeit meist schon recht gut stimmt, aber die Höhe große Abweichungen haben kann (während die Höhenänderungen, die hier für die Berechnung wichtig sind, wiederum recht genau sind). Aber ob die Leistungsdaten stimmen, kann ich überhaupt nicht beurteilen. Und wenn die Geschwindigkeit vom GPS stammt, dann ist die vermutlich auch so hingeglättet, dass es gut aussieht und nicht ganz falsch ist, aber mit hochpräzisen Messungen dürften diese Geschwindigkeitsdaten nicht immer viel zu tun haben.

Daher habe ich jetzt die neue Version des Diagramms (mit Leistungsberechnung) als Standardversion installiert, und zudem noch seltener benutzte Eingabefelder in eine Auswahlbox ausgelagert; so wird eine Zeile auf dem Bildschirm gespart, und man kann trotzdem mehr Dinge interaktiv verändern. Zudem auch noch das Glätten der Daten dort untergebracht:
https://christoph-moder.de/fahrrad/powermeter2diagram.php?demo&HR=0&HR_synth=0&speed_gps=0

 

[Christoph Moder]

Mir ist gerade noch ein Fehler aufgefallen:

P_in = get_in_val(IN_MUSCLE, i, 0) * (1 - params['dtr'] / 100) + P_down + P_decel;

Das hier muss natürlich so geändert werden, dass nicht die Tretleistung aus der Datei verwendet wird, sondern die möglicherweise geglättete Version, wie sie im Diagramm zu sehen ist.

Ist jetzt behoben.

 

[labella-baron]

Hier mal der Ausschnitt aus dem Code; anfangs wird calc_speed auf den Wert des vorigen Punkts gesetzt, falls die Bremsleistung 0 ist; ansonsten auf den Wert der gemessenen Geschwindigkeit.

Ohne Testumgebung ist es für mich halt schwierig für eine bestimmte Stelle nachzuvollziehen, ob der Algorithmus wirklich das macht was er soll. Hier wird doch wirklich gebremst - wieso wird dann nicht die gemessene Geschwindigkeit genommen:

Wenn man nachrechnet ist dort sogar die Eingangs- exakt der Ausgangsleistung.
Auch an vielen anderen Stellen ist es nicht plausibel:


Bei meiner Messung nahe Elfershausen dürften die beiden Bremsungen am Anfang vermutlich auch aus der Sekunden-Interpolation des Spline-Höhenverlaufs hervorgehen, da sich dort das Gefälle stark ändert.

Edit: sehe gerade, dass du auch etwas entdeckt hast - ist es dasselbe Problem?

 

[Christoph Moder]

Ohne Testumgebung ist es für mich halt schwierig für eine bestimmte Stelle nachzuvollziehen, ob der Algorithmus wirklich das macht was er soll.

Ich habe auch keine andere Testumgebung. Ich weiß nur, wie es funktionieren sollte, und schaue mir die Ergebnisse nach Plausibilität an (d.h. wenn etwas nicht stimmt, habe ich einen guten Verdacht, wo ich suchen muss), und lese den Code noch einmal ganz genau.

Hier wird doch wirklich gebremst - wieso wird dann nicht die gemessene Geschwindigkeit genommen:

Das ist ja immer die Frage, ob wirklich gebremst wird – wir können es ja nicht wissen. Aber ja, die Simulation nimmt das hier an.

Und: Ja, es wird die gemessene Geschwindigkeit als Basis genommen; aber aus der Leistungsbilanz ergibt sich offenbar, dass sich diese mit der gemessenen Geschwindigkeit schlecht erklären lässt, sondern nur mit einer höheren.

Bremsung bedeutet ja hier nur: Man nimmt an, dass die vorige berechnete Geschwindigkeit nicht gültig ist, sondern geht lieber von der gemessenen Geschwindigkeit aus. Aber da man nicht weiß, wie stark gebremst wurde, wird auch keine Bremsenergie abgezogen. Daher ist es gar kein Wunder, dass die Kurven bei Bremsungen auseinander laufen. Irgendwann ist die gemessene Geschwindigkeit dann so niedrig, dass P_down und P_decel entsprechend klein geworden sind, und darum die berechnete Geschwindigkeit dann auch wieder nahe an der gemessenen Geschwindigkeit liegt.

Der entscheidende Punkt ist: Berechnet wird die Energiebilanz nur aus:

• P_roll
• P_air
• P_up
• P_accel
• P_muscle
• P_down
• P_decel

Die Bremsleistung geht da überhaupt nicht ein. Denn wir kennen sie ja nicht. Bremsleistung ist das, was übrig bleibt. Und so kommt es, dass die gemessene Geschwindigkeit sinkt, weil in der echten Energiebilanz die Bremsleistung dabei ist, bei der berechneten Geschwindigkeit aber fehlt.

Edit: sehe gerade, dass du auch etwas entdeckt hast - ist es dasselbe Problem?

Meinst du meinen vorigen Post? Nein. Das bezieht sich nur, wenn man P_muscle glättet. Dann wurde nämlich die geglättete Version angezeigt, aber mit der rohen Version gerechnet – was nicht wirklich falsch ist, aber irreführend.

 

[Fritz]

Lieber Christoph!
Ich finde das klasse, was du da machst. Ist das jetzt noch im Versuchsstadium und du versuchst es zu optimieren oder kann ich mit deinem Algorithmus bzw. Grafik schon an der Optimierung meines Fahrzeugs arbeiten?
Vielleicht werde ich alt und meine allgemeine Demenz nimmt stetig zu. Bisher dachte ich, ich könnte das meiste verstehen. Ehrlich gesagt, weiß ich nicht so genau wie ich damit arbeiten kann und etwas verbessern. Z.B. verändert sich der Rollwiderstand sehr stark, obwohl ich meine, dass sich die Umstände garnicht so sehr verändern (Belag, Steigung, Kraft).

 

[Christoph Moder]

Ich finde das klasse, was du da machst.

Vielen Dank!

Ist das jetzt noch im Versuchsstadium und du versuchst es zu optimieren oder kann ich mit deinem Algorithmus bzw. Grafik schon an der Optimierung meines Fahrzeugs arbeiten?

Ich sehe das schon als weitgehend fertig/stabil an. Technisch gesehen ist es ja nichts anderes als die Kreuzotter-Berechnung, angewendet auf jeden Datenpunkt.

Was ich in letzter Zeit gemacht habe bzw. noch mache:

• Die Benutzung bequemer/interaktiver machen, damit man leichter herumprobieren kann.
• Die Darstellung intuitiver/verständlicher machen.

Letztendlich ist es einfach nicht möglich, aus begrenzen Eingabedaten die perfekte Antwort zu berechnen. Statt dessen muss man herumprobieren und herausfinden, wie es vielleicht sein könnte – zusammen mit Hintergrundwissen über die Strecke und Randbedingungen (Straßenzustand, Wind etc.). Und mein Tool soll einfach dieses Herumprobieren so einfach wie möglich machen.

Man überlegt sich ein Szenario (= Parameter wie Roll- und Luftwiderstand), und die Seite soll so viele Aspekte/Konsequenzen wie möglich und so verständlich wie möglich anzeigen, so dass man gut versteht, was eigentlich passiert und ob das so sein könnte.

Ehrlich gesagt, weiß ich nicht so genau wie ich damit arbeiten kann und etwas verbessern. Z.B. verändert sich der Rollwiderstand sehr stark, obwohl ich meine, dass sich die Umstände garnicht so sehr verändern (Belag, Steigung, Kraft).

Je genauer man hinschaut, desto komplizierter wird es. Und ich habe lediglich ein Werkzeug gebaut, mit dem man die Daten sehr genau anschauen kann.

Dabei gibt es natürlich systematische Probleme; z.B. die Daten können beliebig fehlerhaft sein – und wir kennen die Fehler nicht, sondern sehen höchstens, dass eine Kurve unrealistisch aussieht oder nicht zu der gefahrenen Strecke passt. Oder die Bremsungen, die prinzipbedingt nicht in den Daten enthalten sind.

Und dann sehe ich auch immer deutlicher, dass anscheinend ein Rollwiderstands- und ein Luftwiderstandskoeffizient eine Fahrt nicht erklären kann. Ursache sind wohl Dinge wie unterschiedlich guter Straßenbelag, unterschiedliche Windverhältnisse ... und dieses Problem kann man nicht lösen, sondern muss sich dessen bewusst sein.

Und zur Optimierung: Ich weiß nicht, ob man damit wirklich ein Fahrzeug gut optimieren kann; denn die Velomobile sind ja schon recht gut. Da braucht man wirklich eine Teststrecke mit sehr konstanten Bedingungen, damit man was aussagen kann. Ich sehe mehr Potenzial in der Streckenplanung und der Leistungseinteilung; wenn man sieht, wo die Leistung eigentlich hingeht, kann man besser einteilen, wo es sich lohnt, Gas zu geben und wo nicht.

 

[Fritz]

Ich sehe mehr Potenzial in der Streckenplanung und der Leistungseinteilung; wenn man sieht, wo die Leistung eigentlich hingeht, kann man besser einteilen, wo es sich lohnt, Gas zu geben und wo nicht.

Ach so. Das hätte ich nicht vermutet. Meine Idee war eher auf einer gleichbleibende Strecke versuchen mit gleicher Leistung zu treten oder zu rollen und dann Dinge am VM zu verändern. Mit und ohne Visier. Helm auf und Helm ab. 1, 2 oder gar keine Außenspiegel. Verschiedene Mäntel. Spur verstellen usw. Luftdruck.

 

[Christoph Moder]

Meine Idee war eher auf einer gleichbleibende Strecke versuchen mit gleicher Leistung zu treten oder zu rollen und dann Dinge am VM zu verändern. Mit und ohne Visier. Helm auf und Helm ab. 1, 2 oder gar keine Außenspiegel. Verschiedene Mäntel. Spur verstellen usw. Luftdruck.

Du kannst es ja mal versuchen. Aber dann eher Rolltest; die Tretleistung zappelt so massiv herum, da kann ich mir nicht vorstellen, wie man das halbwegs reproduzierbar hinbekommt. Ich könnte mir vorstellen, dass ein Hochgeschwindigkeits-Rolltest für die Aerodynamik und ein Niedriggeschwindigkeits-Rolltest für den Rollwiderstand interessant sein könnten.

 

[labella-baron]

Das ist ja immer die Frage, ob wirklich gebremst wird – wir können es ja nicht wissen. Aber ja, die Simulation nimmt das hier an.

Nein, sie nimmt es in meinem ersten Bild eben nicht an!
Ich habe ja dort den nachfolgenden grünen Bereich (P_brake) extra dargestellt. Z.B. bei 18,32km sind es 2453W Bremsleistung.
Meine Parameter sind so gewählt, dass die Drivetrain-Verluste in etwa in/out entsprechen.

 

[Christoph Moder]

Nein, sie nimmt es in meinem ersten Bild eben nicht an!

Kannst du doch nicht wissen! (Jedenfalls nicht aus dem Bild.)

Zur Klarstellung: Dich irritiert, dass die berechnete Geschwindigkeit weiter ansteigt? Ja, das tut sie, weil die Bremsleistung unbekannt ist. Es ist offensichtlich ein immer größerer Leistungsüberschuss vorhanden, und dieser führt dazu, dass die dunkelblaue Kurve ansteigt. Man kann eben nicht sowohl annehmen, dass der Leistungsüberschuss an falschen Parametern liegt und deshalb anhand der Parameter eine passendere Geschwindigkeit berechnen, als auch den Leistungsüberschuss als Bremsleistung deklarieren. (Die Bremsleistung wird als grüne Kurve angezeigt, aber nicht für die berechnete Geschwindigkeit verwendet, sondern diese an diesen Stellen lediglich von der gemessenen Geschwindigkeit aus berechnet, statt der vorigen berechneten Geschwindigkeit.)

Wo möglicherweise gebremst wird, ist die berechnete Geschwindigkeit einfach nicht aussagekräftig. Aber ich will sie auch nicht einfach dort löschen, weil die Bremsungen ja unbekannt sind – je niedriger die Widerstandskoeffizienten oder das Gewicht, desto mehr Leistungsüberschuss gibt es, und entsprechend Stellen, an denen möglicherweise gebremst wird.

 

[labella-baron]

Ich sehe das schon als weitgehend fertig/stabil an. Technisch gesehen ist es ja nichts anderes als die Kreuzotter-Berechnung, angewendet auf jeden Datenpunkt.

Was ich in letzter Zeit gemacht habe bzw. noch mache:

• Die Benutzung bequemer/interaktiver machen, damit man leichter herumprobieren kann.
• Die Darstellung intuitiver/verständlicher machen.

Ein Leistungsmesssystem im VM ist ja nun mal eine aufwändige und kostspielige Sache. Mein System mit der Aufzeichnung jeder einzelnen Radumdrehung per Smartphone könnte sich ja jeder selbst einfach basteln. Jedoch nützt es nur, wenn man dazu auch das genaue Höhenprofil der Strecke hat. Von meiner Hausrunde habe ich eine GPS-Aufzeichnung mittels Oregon mit barometrischer Höhenkorrektur durch den Luftdruck bzw. kann mehrere erstellen.
Wenn man nun in deinem System diese beiden Datenquellen verfügbar hätte, könnte man in etwa zum einen auf die (eigene) Antriebsleistung an verschiedenen Stellen und auf die verfügbare Bremsenergie z.B. für Rekuperation schließen.

 

[labella-baron]

Zur Klarstellung: Dich irritiert, dass die berechnete Geschwindigkeit weiter ansteigt?

Nein
Mich irritiert, dass die berechnete Geschwindigkeit im Bild nicht bereits bei 18,27km auf die gemessene Geschwindigkeit gesetzt wird, sondern nicht nachvollziehbar erst ca. 110m danach.

 

[Christoph Moder]

Ein Leistungsmesssystem im VM ist ja nun mal eine aufwändige und kostspielige Sache. Mein System mit der Aufzeichnung jeder einzelnen Radumdrehung per Smartphone könnte sich ja jeder selbst einfach basteln. Jedoch nützt es nur, wenn man dazu auch das genaue Höhenprofil der Strecke hat. Von meiner Hausrunde habe ich eine GPS-Aufzeichnung mittels Oregon mit barometrischer Höhenkorrektur durch den Luftdruck bzw. kann mehrere erstellen.

Eigentlich sind das ja alles lösbare Probleme. Man kann beispielsweise einen extra Geschwindigkeitssensor installieren; übliche Leistungsmesser können Sensoren, die via ANT+ oder Bluetooth senden, verwenden. Wenn man dabei einen Sensor nimmt, der via Reedkontakt misst, kann man mehrere Magneten an den Speichen installieren und einen entsprechend kleineren Radumfang angeben. Und eine im Leistungsmesser integrierte barometrische Höhenmessung, idealerweise via GPS kalibriert oder wo man dem Startpunkt eine feste Höhe zugewiesen hat, sollte auch brauchbare Daten liefern.

Wenn man nun in deinem System diese beiden Datenquellen verfügbar hätte, könnte man in etwa zum einen auf die (eigene) Antriebsleistung an verschiedenen Stellen und auf die verfügbare Bremsenergie z.B. für Rekuperation schließen.

Klar, man könnte schon überlegen, wie man mehrere Datenquellen darstellt. Mache ich ja z.B. bei Geschwindigkeit und GPS-Geschwindigkeit so; hilfreich für den Fall, wenn z.B. der Geschwindigkeitssensor ausfällt. Aber dann ist immer die Frage, welche Daten denn jetzt für die Berechnung verwendet werden sollen. Besser wäre es, die Leistungsmesser-Datei zu bearbeiten, und dort die Datenwerte aus mehreren Datenquellen zu kombinieren. Also nur eine Geschwindigkeit und nur ein Höhenwert als Eingabe, statt mehrere Werte, wo unklar ist, welcher denn was taugt und welcher nicht.

Aber keine Ahnung, wie man das sinnvoll machen könnte. Man müsste ja die Datensätze nicht nur kombinieren, sondern vorher auch auf die gleichen Koordinaten bzw. Entfernungsschritte beziehen. Automatisiert wird das nicht gehen, sondern schon etwas Handarbeit erfordern.

Mich irritiert, dass die berechnete Geschwindigkeit im Bild nicht bereits bei 18,27km auf die gemessene Geschwindigkeit gesetzt wird, sondern nicht nachvollziehbar erst ca. 110m danach.

Doch, sie wird bereits dort auf die gemessene Geschwindigkeit gesetzt, und dann angesichts der Leistungsbilanz von dort ausgehend nach oben oder unten korrigiert. Und dabei landet sie nun einmal ungefähr dort, wo der vorige Wert der berechneten Geschwindigkeit ist.

Natürlich ist das unrealistisch; denn falls dort tatsächlich gebremst wird, dann ist die berechnete Geschwindigkeit zu hoch. Aber die gemessene Geschwindigkeit ist genauso unrealistisch; denn bei den angenommenen Parametern wäre es ein großer Zufall, wenn die berechnete Geschwindigkeit genau auf den Wert der gemessenen Geschwindigkeit fiele. Wir wissen schließlich nicht, ob überhaupt gebremst wurde (können das nur aus einem großen Energieüberschuss schließen), und auch nicht, wie stark gebremst wurde. Man sollte die berechnete Geschwindigkeit bei möglichen Bremsungen einfach ignorieren. Ich will sie an den Stellen aber auch nicht einfach weglöschen, weil das vermeintliche Bremsen kann ja auch durch eine plötzliche kurze starke Steigung (die nicht im Höhenprofil auftaucht) oder einen schlagartig schlechteren Straßenbelag verursacht sein. Wir können es nicht wissen, und daher will ich da keine Interpretation aufzwingen.

 

[labella-baron]

Doch, sie wird bereits dort auf die gemessene Geschwindigkeit gesetzt

Sie wird also bei 18,27km auf die gemessene Geschwindigkeit gesetzt, aber wie bereits gezeigt, wird dies nicht gezeichnet:

Durch welches Ereignis oder welche Berechnung erfolgt dann bei 18,37 der Knick nach unten:

Und wieso ausgerechnet dort und nicht schon bei 18,34 oder 18,36?

 

[labella-baron]

Man kann beispielsweise einen extra Geschwindigkeitssensor installieren; übliche Leistungsmesser können Sensoren, die via ANT+ oder Bluetooth senden, verwenden. Wenn man dabei einen Sensor nimmt, der via Reedkontakt misst, kann man mehrere Magneten an den Speichen installieren und einen entsprechend kleineren Radumfang angeben.

Du erinnerst dich was für ein Schrott beim Polar bei höheren Geschwindigkeiten heraus kam?
ANT+ traue ich auch nicht, da es nur jede viertel Sekunde überträgt, wir aber dieser Zeit bei 80km/h mal drei oder mal vier Radumdrehungen haben. Außerdem sollte es ja ohne Powermeter-System gehen.
Die Synchronisation mit dem GPS sehe ich nicht so kritisch: viele kann man so Einstellen, dass sie z.B. nur dann einen Punkt schreiben, wenn wenigstens wieder 10m zurückgelegt wurden, also erst, wenn man wirklich losgefahren ist.

 

[labella-baron]

Meinst du meinen vorigen Post? Nein. Das bezieht sich nur, wenn man P_muscle glättet. Dann wurde nämlich die geglättete Version angezeigt,

Das könnte schon Einfluss gehabt haben: nun ist nämlich bei 18,27km P_muscle>10W und deshalb wird angenommen, dass nicht gebremst wird:

Aber wieso speed_calc im Zickzack nach unten angepasst wird erschließt sich mir immer noch nicht.

Edit: obiges ist noch nicht stimmig

 

[labella-baron]

anfangs wird calc_speed auf den Wert des vorigen Punkts gesetzt, falls die Bremsleistung 0 ist

Jetzt schmeiß ich doch noch meine alten C-Gehirnzellen an
var calc_speed = (P_brake === 0
Wie lautet der Ausdruck welcher P_brake erzeugt?
Ist es erforderlich mit '===' auf Identität zu '0' abzufragen? Ist P_brake denn keine Gleitkommazahl?