In einer GPX Datei sollte die aufgezeichnete Geschwindigkeit des Tracks doch halbiert werden können. Wenn ich dann hingehe und die 50 fps Aufnahme auf die doppelte Zeit rendere, so habe ich einen Film mit halber Geschwindigkeit bei 25 fps. Ist das Gleiche wie eine native 50 fps Aufnahme mit doppelter Geschwindigkeit.

Die Synchronität ist doch eh nicht 100% gegeben. Die Geschwindigkeitsermittlung der Ergo - Gerätes erfolgt ja auch nicht stetig, sondern getaktet und hängt ein wenig hinterher. Geschwindigkeitsänderungen mit einer Flankensteilheit von 100% werde ich niemals ruckelfrei umsetzen können. Ich denke nicht, dass es ein Problem wäre, wenn die Geschwindigkeit mit einer Rampe etwas beruhigt wird. In der Realität findet die Beschleunigung oder das Bremsen ja auch als Rampe statt. Ich sehe halt am Monitor, dass die Geschwindigkeit laufend im Bereich von +/- 3 km/h springt. Mit einer deutlichen Beruhigung würde das Video flüssiger laufen und die Synchronität würde nicht besonders leiden.

Evtl. könnte man einen Einstellwert einbauen, so dass der Nutzer selbst entscheiden kann, was ihm wichtiger ist.

Klar muss die Aufnahmegeschwindigkeit zur getretenen Geschwindigkeit in Relation gesetzt werden ...

Getretene Geschwindigkeit / Aufnahmegschwindigkeit = Faktor der Wiedergabegeschwindigkeit bei VLC

Der Wiedergabezeitpunkt seinerseits definiert dann den GPS - Punkt in der Trackaufzeichnung. Da stört eine Rampe nur insoweit, dass die Beschleunigung oder Abbremsung leicht verzögert (etwas mehr, als es eh schon ist) angezeigt wird.

[Dieser Beitrag wurde 2 mal bearbeitet, zuletzt am 2015-09-25T15:18Z.]

Was soll daran unrealistischer werden. Der Film läuft halt nativ langsamer und bei entsprechender Tretgeschwindigkeit halt normal schnell. Bedeutet ja genauso, dass das Bild jetzt auch total schlecht und unrealistisch ist, da die Wiedergabe meist langsamer ist, als das Original.
Wenn hier nicht seit Jahren das Ruckeln ein Thema wäre und keine Lösung in Sicht ist, könnte man deinen letzten Absatz unterstreichen. Mit der Erkenntnis, dass andere Anbieter bessere Ergebnisse anbieten (Daum), würde ich die Arroganz nicht ganz so weit heraushängen lassen.

Hallo,

eine Rampe für die Geschwindigkeitssteuerung haben wir schon versucht... Das mag der VLC gar nicht. Tatsächlich verändert KWT die Geschwindigkeit des VLC nicht so oft wie dies auf dem Bildschirm bei den Zahlenwerten angezeigt wird. Die Zahlenwerte zeigen nur die Eingangswerte für die Videosteuerung und sind nur als Indiz zu sehen wie gerade das Verhältnis ist.

KWT Berechnet das Verhältnis der Geschwindigkeiten und Rundet dies Großzügig damit kleinere Änderungen gar nicht erst berücksichtigt werden.
Zusätzlich dazu wird dann immer noch geschaut wie Synchron die Video Position zur Fahrer Position ist und wenn nötig wird das Verhältnis so angepasst das es wieder synchron wird.

Das Glätten der Geschwindigkeit haben wir auch versucht aber das Ergebnis war unschön.

Einen Grund für die Ruckler muss es ja geben. Da die Videovorschau vor Trainingsbeginn den Film mit einer festen Geschwindigkeit so flüssig anzeigt, wie es das Videomaterial zulässt, würde ich davon ausgehen, dass es weder an Hardwareproblemen liegt, noch am VLC.

Gerade die Synchronisation der Fahrerposition zum Videobild könnte hier eine "Fehlerquelle" sein, die Ruckler verursacht. Die Synchtonisation kann nur in eine Richtung funktionieren. Die Zeitachse des Videos bestimmt die GPS - Position des Fahrers. Sobald versucht wird den Film an die GPS - Position anzupassen wird es ruckeln.
Die Tretgeschwindigkeit regelt die Videogeschwindigkeit. Die Videogeschwindigkeit bestimmt die GPS - Position, bzw. die ausgelesene Abspielzeit. Korrekturen für die Synchronisation werden dann halt nur in der GPS - Position gemacht, denn eine Korrektur in der Karte ist weniger störend.

Bitte nicht falsch verstehen ... mir gefällt das Kettlersystem im Gesamtsystem, Gerät und Programm, sehr gut.
Allerdings ist die Videofahrt ein Schlüsselelement, welches einfach nicht zufriedenstellend funktioniert. Ich denke, dass es nicht schaden kann, hier intensiver tätig zu werden, um den Kunden ein tolles Produkt zu liefern. Da wir Kunden das genaue System nicht kennen, bleibt uns ja nichts anderes übrig als mit Mutmassungen neue Gedankenansätze zu liefern, oder alt neu zu beleben. Als jemand, der in der Regelungstechnik zuhause ist, mag ich nicht glauben, dass das Problem unlösbar ist.

Hallo Leute

Ich kennen auch verschiedene Systeme unter anderem MTB- Simulator.
Ziemlich billig und Updates immer umsonst!!
Ich glaube das läuft aber mit Java.
Dort braucht man nur eine mp4 Datei.
Keinerlei RLV Dateien.
Und das System läuft absolut nur so schnell wie ich trete, und dann auch ohne Ruckler und Gepixel wenn ich zu schnell oder zu langsam bin.
In die Kurven fahre ich auch mit der Geschwindigkeit wie in Wirklichkeit,- also nicht mit 70h/km in die Spitzkehre.

Vielleicht sollte der Ansatz vom Video einmal überdacht werden.
Der MTB Sim hat ziemlich wenige User.
Kettler vielleicht weltweit tausende.
Da müsste man für die User doch das Optimale finden können, oder nicht?
Ich habe mal was von DirektShow gehört wo es super laufen soll!!

Ich ärgere mich immer wenn ich einen eigenen Film vom Rennen erstellen, und dann soll man noch eine RLV erstellen.
Das ist viel zu kopliziert. Die GPX müsste eigentlich auch dann immer überarbeitet werden.
Wer weiß das schon wie das genau funktioniert.
Es gibt so oft Stellen wo man anhalten muss, zu langsam fährt oder auch wieder zu schnell für KWT.
Also gibt es auch immer wieder Stellen wo das Video beschleunigt oder 1-2 Sekunden ausläßt oder pixelt, weil man für KWT zu langsam fährt.

Es macht unheimlich Spaß mit eigenen Renn oder Unlaubsvideos in KWT zu fahren.
Es ist kurzweilig beim Fahren aber viel zu Mühsehlig bei der Erstellung.
Wer von Euch kennt sich mit RLV Erstellung aus oder bei der GPX Bearbeitung.
Vielleicht schreibt mal einer eine Anleitung

Gruß Johannes

KWT 3.0.4.18 / Win11-64/32Gb RAM/SSD
Garmin Neo Bike Plus (2025) : 973 km
Trek Supercaliber 9.9 XX1 (2025) : 325 km
Trek Domane SLR7 (2025) : 122 km
Rotwild RCC 1.2R Team: (2025) : 0 km
Hürzeler Cube Mallorca (2025) : 239 km
je 1x Dahon/1x Tern Klapprad mit RRKurbel (2025) : 30 km
Specialized Epic Marathon (2025) : 26 km
Staiger Einkaufsrad (2025): 187 km
Laufen 2025 : 16 km
Gehen 2025 : 96 km
Rudern 2025 : 116 km
___________________ 65 Jahre

Hallo,

da kommen ja Ansätze...

Mal ganz grob.
Es gibt eine Linie mit einer Länge in km.
Diese Strecke stellt die Tour dar.

Nun gibt es dazu ein Video das über eine Steuerdatei mit der Linie verknüpft wird und zwischen den Verknüpfungspunkten Metadaten wie Fahrgeschwindigkeit bei der Aufnahme hat.

Der Fahrer fährt nun mit einer Geschwindigkeit und legt die Strecke zurück. Seine Position in km ändert sich stetig.

Über die Steuerdaten kann die Software nun die Position im Video ermitteln und die Metadaten dieser Position lesen um die Abspielgeschwindigkeit zu berechnen.


Also wie bitte soll die Zeitachse des Videos die Position des Fahrers bestimmen???


Würden wir Trainingszeit = Videoposition setzen dann wäre das ganze System überflüssig. Dann kann man das Video auch gleich im VLC abspielen und KWT weg lassen.
Die gefahrene Geschwindigkeit wäre dann vollkommen egal.



Gruß

Wolfgang

Wenn man das Video auf einer Zeitachse mit der Teilung von einer Sekunde hätte (die native Abspielgeschwindigkeit, also VLC Faktor 1,0), so könnte man zu jeder dieser Sekunde eine Geschwindigkeit bestimmen, die während der Aufnahme gefahren wurde.

Für das Abspielen des Videos ist die GPS - Position erstmal völlig unerheblich, sondern nur die Tretgeschwindigkeit des Nutzers entscheidend

Setzt man die Tretgeschwindigkeit des Nutzers mit der Aufnahmegschwindigkeit des Videos ins Verhältnis, so erhält man den Faktor für die Abspielgeschwindigkeit des Videos.

Wiedergabegeschwindigkeit = Tretgeschwindigkeit des Nutzers geteilt durch die Geschwindigkeit bei der Aufnahme.

Dieser Faktor kann nun über jede Sekunde im Video bestimmt werden.

Aus dem VLC wird also die Videoposition ausgelesen, die Geschwindigkeit während der Aufnahme zu diesem Zeitpunkt bestimmt und durch die gestrampelte Geschwindigkeit des Nutzers geteilt.

Ich erhalte also stetig den Faktor für die Abspielgeschwindigkeit des VLC, so dass der Nutzer schon die Abspielgeschwindigkeit steuert.

Die Geschwindigkeit des Nutzers wird ca. alle 0,5 bis 2 Sekunden bestimmt (je nach RPM). Diesen Werteverlauf sollte man ausreichend beruhigen und eine Beschleunigung oder Abbremsung per Mindestrampe begrenzen.

Ich habe gestern mal ein wenig im VLC ohne Kettler mit der stufenlosen Geschwindigkeitsregelung der Abspielgeschwindigkeit herumgespielt und festgestellt, dass der VLC bei Beschleunigung unempfindlicher reagiert, als bei Reduzierung der Abspielgeschwindigkeit, was natürlich auch (womit wir wieder bei der Videoerstellung sind) an den fps liegt.
Jedenfalls kann ich den Schieberegler der Wiedergabegeschwindigkeit wunderbar mit den Pfeiltasten in der Teilung 0,02 erhöhen und verringern und erhalte ab ca. Faktor 0,7 ein recht flüssiges Bild. Unter diesem Faktor wird das Gezuckel durch die niedrigen fps recht störend.

Um nun natürlich auch noch den Tretwiderstand zu steuern, muss das KWT natürlich auch die GPS - Position des aktuellen Videobildes kennen, die Höhe, Steigung, etc.
Diese ganzen Werte können aber, genauso wie die Geschwindigkeit der Videoaufnahme auch je Sekunde des Videos hinterlegt sein, so dass das Auslesen der aktuellen Videoposition zu diesen Werten führt.

Ich kann nicht beurteilen, wie KWT die Sache handhabt. Ich vermute aber, dass beim KWT die Videolösung auf die normalen Tourfahrten ohne Video aufgesetzt wurde, bei der nicht nur die getretene Geschwindigkeit im Verhältnis zur Aufnahmegeschwindigkeit für die Wiedergabe berücksichtigt wird, sondern über die GPS - Position die Wiedergabeposition des Videos angepasst wird. Ich wüsste jedenfalls nicht, woher die Ruckler sonst kommen sollen ...

Hallo,

das Video ist nur eine Ansicht der Tour aber keinesfalls erforderlich. Eine "Tour mit Video" kann auch gefahren werden ohne das man die Video Datei besitzt. Von daher klappt der Ansatz schon mal nicht.

Dein Ansatz würde auch so nicht sauber funktionieren da sich die Abspielgeschwindigkeit des VLC stetig ändern würde und damit die Videoposition mit der Zeit abweichen würde.
Man ersetzt die Streckenmessung mit der Videoposition und lagert diese aus der KWT Logik aus... Das gefällt mir gar nicht.

Unabhängig von den ganzen Vermutungen habe ich noch immer nicht verstanden wie stark diese Ruckler sind. Wie oft pro Sekunden ungefähr?

Ich habe bei mir bei manchen Videos so gut wie gar keine.
Bei anderen habe ich bei niedrigen Geschwindigkeiten ungefähr alle 2-3 Sekunden einen kurzen Moment des Stockens.
Allerdings hängt das auch von der Abspielgeschwindigkeit ab.
Da diese in so Regemäßigen abständen auftauchen glaube ich eigentlich nicht an ein Problem der Geschwindigkeitsansteuerung.
Entweder gibt es da noch einen anderen Vorgang innerhalb von KWT der die UI alle 2-3 Sekunden kurz einfriert oder der VLC hat da noch ein Problem bzw. die Integration des VLC.

Gruß

Wolfgang