Bremsen mit Problem...

[EASY]

Hallo Neo,

... ich weiß... schon wieder das Thema "Bremsen"... aber ich stelle es hier unter "Technischer Support" ein, da dieser Versuch nur eingeschränkt einsetzbar ist...

Ich bin das Thema Bremsen etwas mathematisch angegangen und mein Ziel war es einen definierten Bremsweg umzusetzen... und mit nur einer Ereignisgruppe jeden beliebigen Zug zum Bremsen zu bringen... das Ereignis "Bremsen_aktivieren" muß nur die Variablen "Lok" und "weg" bereitstellen und die Ereignisgruppe "Bremsen_Lok_Weg" aktivieren.

ich bin es mathematisch angegangen und von einer linearen Verzögerung ausgegangen... was die Mathematik vereinfacht.
v=Anfangsgeschwindigkeit der Lok
vz=Vorzeichen von v
weg=gewünschter Bremsweg
dt=Zeitintervall für Timer
t=benötigte Zeit bis zum Stillstand

daraus ergibt sich:
t=weg/vq mit vq=mittlere Geschwindigkeit = v/2 (lineare Verzögerung)
anz=t/dt = Anzahl der Schritte (Anzahl Durchlauf Timer)
dv=v/anz = Geschwindigkeitsreduktion je Schritt

... soweit die Theorie... nun kommt das (bekannte) Problem:
Dieser Algorithmus setzt eine Synschronisation zwischen Darstellung und Berechnung voraus... und dies ist (leider) nicht gegeben, wenn der Timer schneller auslöst, als die Bildverarbeitung (dt < 1/fps)... die auflaufenden Ereignisse von "Countdown läuft ab" werden zwar abgearbeitet aber erst aus einen "Zwischenspeicher" bein nächsten Frame...
...so bricht die Synchronisation zwischen Berechnung und Darstellung und die Lok "schießt über das Ziel hinaus"...

Daraus ergibt sich meine Frage an Neo:
Wird aus dem "Zwischenspeicher" immer nur ein ein Ereignis(-Durchlauf) abgerufen? (... für den Fall, das der Timer innerhalb eines Frames mehrmals auslöst)... mir kommt es so vor...
... gibt es für diesen Fall eine Lösung?

Für einen einfachen Versuch: "Vertikale Synchronisation" ein -> 60 fps (= 0.0166667s) und dt auf 0.01 setzen... (dt<1/fps)

Bremsweg1.mbp

Gruß
EASY

Bearbeitet 1. Januar 2017 von EASY
Schreibfehler beseitigt

[trevor]

Hi Easy, and "Happy New Year"

With ANY sampled system like this, there are ALWAYS issues with control systems mechanics. That is, MBS steps the motion of the simulation at some rate, generating events at each step. however, in the case of a locomotive passing a sensor point, that can mean the loco can be anywhere from "right on the edge of the sensor point" to being "speed x step_time distance past it". Then add in the fact that your speed command also gets delayed in the pipe.... well you get the rest.

From my own experiences with my controller I have found there is no real way around this. My controller uses the initial assumption that the event is worst case... i.e. the event is late,  to calculate the deceleration rate. Furthermore, I calculate the deceleration to a target point short of a final stop point sensor track.  I then decelerate to a "creep speed" around that point and let the locomotive slowly roll to the stop point. That method works most of the time and looks realistic.

However, even with all that.. things can conspire against you. That's why you still need "Lock Tracks" after the stop point.

I was also not sure if you were saying you were trying to use the frame clock to synchronize this, if you are.. don't.
The frame clock is not directly tied to simulation time / distance. Use a timer instead.

(By the way, a better way to do deceleration is to actually figure out the distance remaining to the stop point from the front (or back) of the train at each step and do the math using that value. Unfortunately.. I have yet to determine a fool proof method of determining that number under all circumstances that does not require way too many calculations.)

Best Regards.. 
T
 

[EASY]

Hi trevor... thanks for and also "Happy New Year",

i knew the problem and i knew that i will fail at low fps... but i wanted to know what really happens if i try to realize a math function [f(t)] only with "event control" (event manager) of MBS -> EV... and i wanted to know if Neo got an idea to solve this problem.

Zitat

vor 4 Stunden schrieb trevor:

I was also not sure if you were saying you were trying to use the frame clock to synchronize this

To solve my math function f(t) i use a timer within the EV. All events and actions are calculated (sequentially) in MBS at each frame so 1/fps is the clockfrequenz for EV... so if the timer in EV ist faster then 1/fps (-> event "timer expires") is detected with the next frame and the action in MBS is too late. (Apart from what you have written "With ANY sampled system...").-> Synchronization (math calculation <-> shown in MBS) is no longer present... ( I have tried it ... with a "correction" factor [known fps provided] it is possible to minimize the "error" greatly...)

Zitat

vor 4 Stunden schrieb trevor:

However, even with all that.. things can conspire against you

... i.e. Windows (... MBS has to wait... my process is more important )

Zitat

vor 4 Stunden schrieb trevor:

The frame clock is not directly tied to simulation time / distance. Use a timer instead.

... see here

Zitat

vor 4 Stunden schrieb trevor:

(By the way, a better way to do deceleration is to actually figure out the distance remaining to the stop point from the front (or back) of the train at each step and do the math using that value. Unfortunately.. I have yet to determine a fool proof method of determining that number under all circumstances that does not require way too many calculations.)

... very interesting problem if there are cuved tracks or track switches within the deceleration way...
... please let me know when you found a "fool proof method that does not require way too many calculations"... with many calculations i have already done (calculating a track distance)...

EASY

Bearbeitet 1. Januar 2017 von EASY

[Neo]

Hallo Easy,

vor 22 Stunden schrieb EASY:

Dieser Algorithmus setzt eine Synschronisation zwischen Darstellung und Berechnung voraus... und dies ist (leider) nicht gegeben, wenn der Timer schneller auslöst, als die Bildverarbeitung (dt < 1/fps)

hier gibt es ein Missverständnis. Timer/Countdowns können nicht schneller als die Darstellung auslösen, die Verarbeitung der EV ist an die Anzeige gekoppelt. Jedes Frame, wenn die EV verarbeitet wird, werden die Timer um die Zeitdifferenz zum letzten Frame fortgesetzt, und falls sie auf 0 (oder darunter) fallen, ausgelöst. Das passiert alles in einem Schritt.

Das Problem kannst du leider über die EV nicht lösen, da die EV immer erst dann ausgelöst wird, nachdem ein Zug mit seiner Ist-Geschwindigkeit fortbewegt wurde. Ein Bremsen müsste aber direkt bei der Fortbewegung ansetzen, indem dort die negative Beschleunigung direkt mit berücksichtigt wird. Das kann daher nur das MBS lösen, da die EV keinen Zugriff auf solche Berechnungen hat.

Das Thema Bremsen/Beschleunigung wird ja immer populärer, weshalb du da nicht zu viel experimentieren brauchst, ich werde mit der neuen Version zeitnah versuchen, dass Problem sauber direkt im Studio zu lösen.

Viele Grüße,

Neo

[EASY]

Hallo Neo,

Zitat

vor 47 Minuten schrieb Neo:

hier gibt es ein Missverständnis. Timer/Countdowns können nicht schneller als die Darstellung auslösen, die Verarbeitung der EV ist an die Anzeige gekoppelt. Jedes Frame, wenn die EV verarbeitet wird, werden die Timer um die Zeitdifferenz zum letzten Frame fortgesetzt, und falls sie auf 0 (oder darunter) fallen, ausgelöst. Das passiert alles in einem Schritt.

... ist auch logischer wenn man die EV Verarbeitung als solche betrachtet und den Timer nicht als "besonders" ...
... da bin ich auf das Denken von einem "Timer" in einem Programm hereingefallen...

Zitat

vor 51 Minuten schrieb Neo:

Das Thema Bremsen/Beschleunigung wird ja immer populärer, weshalb du da nicht zu viel experimentieren brauchst, ich werde mit der neuen Version zeitnah versuchen, dass Problem sauber direkt im Studio zu lösen.

... darüber werden sich bestimmt einige freuen.

Gruß
EASY

[BahnLand]

vor 51 Minuten schrieb EASY:

Zitat

vor 1 Stunde schrieb Neo:

Das Thema Bremsen/Beschleunigung wird ja immer populärer, weshalb du da nicht zu viel experimentieren brauchst, ich werde mit der neuen Version zeitnah versuchen, dass Problem sauber direkt im Studio zu lösen.

... darüber werden sich bestimmt einige freuen.

Stimmt!

Das macht insbesondere die EV um einiges einfacher!

Viele Grüße
BahnLand

[Vermanus]

Hallo Leute,

einfach Kippschalter betätigen und anschauen.

VGaÖ

Vermanus

BeschleunigenBremsen.mbp

[trevor]

15 hours ago, EASY said:

To solve my math function f(t) i use a timer within the EV. All events and actions are calculated (sequentially) in MBS at each frame so 1/fps is the clockfrequenz for EV... so if the timer in EV ist faster then 1/fps (-> event "timer expires") is detected with the next frame and the action in MBS is too late.

Yes indeed, and that "error" can be compounded at each sample point....

I am waiting with great anticipation and interest for the version 4 solution. That gives us deceleration and acceleration values to set, though if it is simply those numbers, there will still be the initial setting delay which is always the one with the biggest error.

[trevor]

2 hours ago, Vermanus said:

einfach Kippschalter betätigen und anschauen.

Hi Vermanus, happy New Year

Your sample is cool and illustrates the issue nicely... I ran some data collection on it.

Assuming you wanted to stop before hitting the next track...

60 FPS x1 Simulation : Stop Distance 15.77 mm Late +- 0.918 mm
60 FPS x4 Simulation : Stop Distance 31.24 mm Late +- 4.844 mm
17 FPS x4 Simulation : Stop Distance 161.76 mm Late +- 6.02 mm

(Based on a sample size of 20 on each)

 

Bearbeitet 2. Januar 2017 von trevor

[trevor]

17 hours ago, EASY said:

... very interesting problem if there are cuved tracks or track switches within the deceleration way...
... please let me know when you found a "fool proof method that does not require way too many calculations"... with many calculations i have already done (calculating a track distance)...

Well... interestingly, there are sufficient commands through the plug-in interface to permit code to know the linear lengths of all sections of track including each spur path so it is actually a fairly simple matter to calculate the linear distance from any point on the track to some other point on the track, all be it with a little pre-processing on start-up.

There is even a nice command that tells you how far along a particular track the origin of a piece of rolling stock is and which direction it is pointing...

However, the real killer is trying to figure out exactly where the front or rear of the train is on the track. Since the XYZ origin of rolling stock is not fixed, nor is it's initial orientation, you can't calculate where the load edge is relative to the origin without flipping a coin or two. And that's just for the locomotive.... multiply that by however many wagons or carriages you have attached and you quickly get lost in guesswork.  

Moreover... if you happen to pick up, or lose, a wagon or two on your travels (intentionally or otherwise...) there are no events to tell you that happened.

I have contemplated making my controller run some code to place a copy of each populated rolling-stock, one at a time, on a known piece of straight track and use the distance measure command to check its extents from each end of the track. That, with that directional location command, would get me the information I would need for each vehicle. I'd make that part of the start-up code and store the results as variables in the rolling-stock themselves so I would not have to repeat it every time.

Then I could compare ends with ends to figure out the trains. ... but... it's a lot to process on a heavily stocked layout and, with version 4 coming soon... I am reluctant to go that far right now.

BTW: There IS a whole other way to do deceleration that does NOT involve timers at all. That is, if you break up your deceleration track into NUMEROUS small segments of known length, you can pre-calculate the absolute speed the train needs to be going when it enters each segment and apply it appropriately. Doing that in the EV though is a tad blah. If I were to try it, I would attach each speed as a variable to the track sections themselves so you can just fetch it as a trigger variable. I'd set those variables to be percentages and multiply that against the initial speed grabbed on entry to the first one. You will still have the same error issues at the fast end, but since the error effect diminishes with speed it should correct itself by the time you reach your target.

However, bare in mind, more segments means more events / painting, which means more FPS lag. For ultimate purism, a combination of both methods might work best,  i.e. decelerate with a timer down to an end section of multiple small tracks.

[EASY]

Hi trevor,

Zitat

vor 5 Stunden schrieb trevor:

... with version 4 coming soon... I am reluctant to go that far right now.

... i made a little test... i do not think reality is better... (trying to stop at a point from high speed)

EASY

[Vermanus]

Hallo Leute,

zuerst Happy New Year auch Euch allen!!!

@trevor The train should stop exactly after the defined way (in my case 1000mm). A depence on fps should be small. The counter should work with every fps in the same way. Some differences you get, because splitting the braking-way in 30 parts is maybe not exact enough. More high the speed and more short the braking-way is, more higher is the difference. I think its a rounding problem. And if the section-time (1/30) goes below 0,01sec then the counter cannot handle it.

@EASY If I have it right understood: The maximum braking difference is about 40mm, so taking a track with 80mm should be safe for blocks.

Best regards,

Vermanus

 

[trevor]

13 hours ago, Vermanus said:

A depence on fps should be small.

Sorry, but FPS and simulation rate is very important....

Since MBS handles events between frames, the timer expiration event is NOT handled until the next frame end. For fast frame rates that latency is a small time, but it becomes much more obtrusive the slower the frame rate. Worse, it is ALWAYS a positive number and accumulates your error over the deceleration steps. Similarly with simulation rate. At 4x speed the motion is effectively stepped at 4x train speed.. and any errors introduced by latency are thus magnified.

Remember, the trains motion is NOT directly dictated by the frame rate, but rather, by some other clock that measures elapsed simulation time within the MBS code.

[Vermanus]

vor 3 Stunden schrieb trevor:

Since MBS handles events between frames, the timer expiration event is NOT handled until the next frame end.

Thank you for this information. I always suspected in this direction, but I have been blocked. On a request if the counter runs real-time it was agreed. So the physical-formular and the cutting into sequences is basicly correct, but if the computer is too slow, it will not work anymore correct. I hope NEO will solve it in a simple method! (Startpointspeed - Distance- Endpointspeed). All other methods (acceleration/braking-character of objects and others) are too much complicated. If you have liitle played with my MBP: you can change input-speed and the braking-distance keeps the same (and otherwise). My "Anlage" C001 (you can watch on youTube) is done about frame-recording (because the live time-fps swaps between 2 and 10 fps).

[trevor]

1 hour ago, Vermanus said:

Startpointspeed - Distance- Endpointspeed).

Yes, I too am hoping the new implementation is smart enough to include a destination point....

[EASY]

Hi trevor,

Zitat

Am 2.1.2017 um 16:45 schrieb trevor:

I have contemplated making my controller run some code to place a copy of each populated rolling-stock, one at a time, on a known piece of straight track and use the distance measure command to check its extents from each end of the track. That, with that directional location command, would get me the information I would need for each vehicle.

... found an other way...
For example "BR 50 001"...
...take the position and dimension...

... take a primitive "Ebene"... the dimensions must be smaller then the loco...

... and put it to the position of the loco...

... mark both and make a (temorary) group...

-> ... the midpoint of the group is the real midpoint of the loco...

math stuff: front of loco is midpoint (x) of the group + loco length/2 ; backpoint of loco is midpoint (x) of the group - loco length/2.

... ungroup and use "Ebene" for the next...

EASY

Bearbeitet 3. Januar 2017 von EASY

[trevor]

11 hours ago, EASY said:

 

... mark both and make a (temorary) group...

Cool... I had not thought of that
Still wont get me the which end is front and which axis  = track axis though. For most stock that's the longest dimension, but, it isn't written in stone..

 

Bearbeitet 4. Januar 2017 von trevor

[EASY]

Hi trevor,

Zitat

vor 5 Stunden schrieb trevor:

Still wont get me the which end is front and which axis  = track axis though. For most stock that's the longest dimension, but, it isn't written in stone..

... the fist part i do understand... but ... try to design a (practical) track vehicle which "is not written in stone"...

EASY

[trevor]

42 minutes ago, EASY said:

try to design a (practical) track vehicle which "is not written in stone"...

lol good point

 

[EASY]

Hi trevor,
 

Zitat

Still wont get me the which end is front and which axis  = track axis though

... you or me or we ... could ask Neo for a Command of this setting of a track vehicle... as a feature request

Note: This is only shown for model creators for own models...

EASY

Bearbeitet 4. Januar 2017 von EASY