Correct Use of Wheel Speed vs Ground Speed in Locomotive Physics

[SteelFill]

After years of development, parts of OR have become quite crowded between different types of train speed (is this the speed of the wheels? the true speed relative to the ground? is it the absolute value of speed? or is it negative in reverse and positive forwards?) This has led to a variety of issues like locomotives exceeding their power rating, wheels spinning impossibly fast during wheelslip, wheelslip being too difficult to recover from, and so on.

I talked about this problem 4 years ago in this Elvas Tower thread but it was only ever partially solved.
Formal bug report can be found here.

This PR refactors all that under one guiding principle: anything that applies force to the wheels should always use the wheel speed. Intuitively, this makes sense, but this also makes sense from a conservation of energy perspective. The transmission of a locomotive does not 'know' the ground speed (except if an advanced wheel slip protection system is present, but that does not change the laws of physics), so the best a locomotive transmission can do is output a certain amount of energy to the motors/gearbox/pistons and then hope for the best. The current implementation allows for the transmission to output a certain amount of energy to the rails in some cases, and then the motor/gearbox/piston energy is adjusted accordingly...which can result in the motor/gearbox/piston power exceeding the power available from the wire/engine/boiler, breaking conservation of energy (this generally occurs during wheel slip).

As an example of breaking the laws of physics, let's assume a locomotive has a dynamic brake table that produces 60,000 pounds of dynamic brake force at 25 mph, but, "oh no!", even though the locomotive is currently moving at 25 mph, the wheels are skidding due to poor adhesion and are actually moving at only 5 mph. Before this PR, the dynamic brake force would still be 60,000 pounds at 5 mph wheel speed because dynamic brake force used the ground speed, not the wheel speed. This 60,000 pound force continues to decelerate the wheels, eventually causing the wheels to start turning in the opposite direction. Before long, the wheels are spinning at -50 mph in dynamic braking (giving a wheel power of 8,000 hp, when our dynamic brakes should only be capable of 4,000 hp, breaking conservation of energy) despite the locomotive moving at 25 mph, which (hopefully) is obviously nonsensical. After this PR, the wheel speed would determine the dynamic brake force, so the wheels spinning at 5 mph would only be given a dynamic brake force of say 12,000 pounds (assuming the dynamic brake curve linearly drops to 0 pounds at 0 mph), which would not be enough to spin the wheels in the opposite direction, producing more accurate response during wheel skid.

Expected results of this PR are:

• Locomotives should behave the same as usual when negligible wheel creep is present. (Wheel creep will affect traction calculations now, but as wheel creep is usually less than 1 mph this effect is unnoticeable.)
• Wheelslip during traction for all locomotive types should lead to the wheels slipping at a more reasonable pace (ie: wheel slip shouldn't exceed the locomotive max speed) and should be easier to correct.
• Wheelskid during dynamic braking for all locomotive types should no longer lead to wheels turning the opposite direction (in the worst case, the wheels should almost come to a halt in the direction of travel) and should be easier to correct.
• The transition between nominal adhesion and wheel slip/skid should be smoother and more stable.

Note that the changes here ended up concentrated on steam locomotives, there's a lot going on there that I don't understand/might not be correct, but my goal here was simply to use wheel speed for steam locomotive physics while preventing physics explosions during wheel slip. Multiple parts of steam locomotive code appeared to have been built with the assumption that steam locomotive physics were being driven at the locomotive ground speed, even when wheel slipping (this leads to nonsensical situations like the cylinders consuming steam as if you are moving 5 mph while the cylinders and wheels are actually going crazy at 50 mph), so some subtle tweaking was required to disable those assumptions but I believe I've avoided potential program crashes and made steam locomotive wheelslip sensible, predictable, and correctable.
(I think this trello card was created in response to this problem on steam locomotives.)

I've tested out all sorts of rolling stock, but I recommend simply trying a bit of everything in situations where wheelslip is likely and checking to make sure wheelslip doesn't lead to nonsensical situations, such as spinning the wheel speed above the maximum speed of the locomotive.

I consider this PR a prerequisite to some of the other work I want to do, particularly electric motor simulation, that would behave suboptimally with the current implementation's use of ground speed for traction calculations.

[cesarBLG]

Please note that it was decided that train speed should be used for the tractive force curves instead of wheel speed. The motivation was that, when applying traction power, there will be a wheel creep and wheel speed will be a little bit higher. However, the tractive force curves available in the manuals may have been measured regarding the train speed, so the output force would be a bit lower than expected. I'm not saying that I agree with this argument, in fact I tried to change that a few years ago, and I was told this. But I would really like getting rid of AbsTractionSpeedMpS and just use AbsWheelSpeedMpS for the traction physics, that's what makes more sense.

I have been working on some adhesion tweaks (I separated the adhesion-related changes from the rheostatic-controller part that I shared with you). In particular, I did further cleanup of the steam engine code (ideally everything should be moved to the SteamEngine class, instead of adding "numberOfEngine" to every method, but that will take some time, so I'm doing it step by step). Also I wanted to get rid of the 'Compensated' motive force output of the axle module. I'll rebase my changes to this branch, so it's ready to go into unstable just after this is merged.

[peternewell]

Whilst I agree that it would be ideal that train speed and wheel speed should be clearly defined and used, I would suggest that any changes in this area should be done with due consideration, perhaps on a use by use basis, as it may impact the user inputs or the physics in OR.

For example, as Cesar has suggested, the typical traction curves shown by a manufacturer and potentially by test results uses the train speed as far as I am aware, so to make it easier for user configuration the user should always be able to use train speed when entering this type of information. This will retain the highest degree of accuracy if prototypical information can be used directly.

I would envisage that slip characteristics would be overlaid these figures as appropriate.

[SteelFill]

Please note that it was decided that train speed should be used for the tractive force curves instead of wheel speed. The motivation was that, when applying traction power, there will be a wheel creep and wheel speed will be a little bit higher. However, the tractive force curves available in the manuals may have been measured regarding the train speed, so the output force would be a bit lower than expected. I'm not saying that I agree with this argument, in fact I tried to change that a few years ago, and I was told this. But I would really like getting rid of AbsTractionSpeedMpS and just use AbsWheelSpeedMpS for the traction physics, that's what makes more sense.

I suppose my thoughts are similar as well, that argument is a bit silly. The wheel creep, particularly with the new adhesion model, is so small that the difference in force applied would be well within the margin of error of a dynamometer/whatever was used to measure the tractive effort. And then the tractive effort curves I've seen and implemented are obviously more theoretical (EMD has provided tractive effort curves that are literally just a plot of a constant horsepower line, no consideration given for wheelslip or power lost to field weakening), where the wheel speed is actually what you want. In my situation where tractive force curves are constant force + constant speed (with exceptions for less typical control systems) using the ground speed gives too much force as I don't attempt to consider creep, allowing things to exceed their horsepower rating depending on the amount of wheel creep.

And, of course, no matter what you need to do something about wheelslip, else you get what I described 4 years ago...similar of which is still possible in dynamic brakes. This is what happens when you get wheel skid on a locomotive with dynamic brakes that are too strong:

Mach 4 in the wrong direction is quite impressive, but that's what happens when ground speed is the reference.

This just feels like a very odd thing to add some parameter like "ORTSWheelSpeedReference ( 1 )". Who's going to understand that? Meanwhile folks have clearly already noticed how extreme wheelspin can be with the existing status quo.

[cesarBLG]

I agree that the discrepancy due to wheel creep will be minimal, and using the wheel speed has much more advantages. Could you create a bug report?

[SteelFill]

I have made a formal bug report on launchpad https://bugs.launchpad.net/or/+bug/2112223

I am still tentatively willing to add additional behavior should it be firmly decided that there is justification to use ground speed sometimes, but I would rather folks keep testing existing content with the behavior as-is to look out for any visible differences. The change is not supposed to be that noticeable except during wheel slip.

(Of course, if I missed something that should/shouldn't use wheel speed, that is still worth noting, keep an eye out for anything unusual.)

[cesarBLG]

openrails/Source/Orts.Simulation/Simulation/RollingStocks/MSTSSteamLocomotive.cs

Line 656 in 6bbd2c6

float absSpeedMpS;

Code using this variable is a candidate, at least to look at. Also, given that we also have AbsSpeedMpS, having another variable named 'absSpeedMpS' is confusing.

[SteelFill]

openrails/Source/Orts.Simulation/Simulation/RollingStocks/MSTSSteamLocomotive.cs

Line 656 in 6bbd2c6

float absSpeedMpS;

Code using this variable is a candidate, at least to look at. Also, given that we also have AbsSpeedMpS, having another variable named 'absSpeedMpS' is confusing.

Looks to me that absSpeedMpS should be the true speed as it's driving lots of systems unrelated to tractive effort...but at the same time, it appears to be entirely redundant to AbsSpeedMpS, can't tell why it would need to be a separate variable.

[cesarBLG]

There's a mix, see

openrails/Source/Orts.Simulation/Simulation/RollingStocks/MSTSSteamLocomotive.cs

Line 6605 in 6bbd2c6

DrawbarHorsePowerHP = (DrawBarPullLbsF * MpS.ToMpH(absSpeedMpS)) / 375.0f; // TE in this instance is a maximum, and not at the wheel???

Also there is

openrails/Source/Orts.Simulation/Simulation/RollingStocks/MSTSSteamLocomotive.cs

Line 4884 in 6bbd2c6

SteamEngines[numberofengine].DriveWheelRevRpS = absSpeedMpS / (2.0f * MathHelper.Pi * SteamEngines[numberofengine].AttachedAxle.WheelRadiusM);

which is even weirder. The whole UpdateCylinders should use wheel speed I believe.

openrails/Source/Orts.Simulation/Simulation/RollingStocks/MSTSSteamLocomotive.cs

Line 7081 in 6bbd2c6

if (WaterMotionPump1IsOn && absSpeedMpS > 0)

: the water pump is attached to the wheels and should also use wheel speed.

[SteelFill]

There's a mix, see

openrails/Source/Orts.Simulation/Simulation/RollingStocks/MSTSSteamLocomotive.cs

Line 6605 in 6bbd2c6

DrawbarHorsePowerHP = (DrawBarPullLbsF * MpS.ToMpH(absSpeedMpS)) / 375.0f; // TE in this instance is a maximum, and not at the wheel???

Drawbar power is measured relative to the couplers, not the wheels, so the true speed is the most appropriate measure there. In real life you wouldn't know the drawbar power without a dynamometer car, but the dynamometer wouldn't care about the wheel speed of the locomotive. (A dynamometer would probably use its own wheel speed or a radar speedometer to calculate power.)

Also there is

openrails/Source/Orts.Simulation/Simulation/RollingStocks/MSTSSteamLocomotive.cs

Line 4884 in 6bbd2c6

SteamEngines[numberofengine].DriveWheelRevRpS = absSpeedMpS / (2.0f * MathHelper.Pi * SteamEngines[numberofengine].AttachedAxle.WheelRadiusM);

which is even weirder. The whole UpdateCylinders should use wheel speed I believe.

The calls to UpdateCylinders have already been changed to use the (attached) wheel speed, that is just a local variable with the same name as the global one (not confusing at all...)

openrails/Source/Orts.Simulation/Simulation/RollingStocks/MSTSSteamLocomotive.cs

Line 7081 in 6bbd2c6

if (WaterMotionPump1IsOn && absSpeedMpS > 0)

: the water pump is attached to the wheels and should also use wheel speed.

And yeah a crosshead pump should use the wheel speed to derive pumping speed (unusual strategies; use wheelslip to intentionally increase pumping rate). Though the energy needed to pump the water may suppress wheel slip...Looks like this could also do with a calculation of the horsepower malus, that is one of the major disadvantages of a crosshead pump.

[cesarBLG]

Drawbar power is measured relative to the couplers, not the wheels, so the true speed is the most appropriate measure there. In real life you wouldn't know the drawbar power without a dynamometer car, but the dynamometer wouldn't care about the wheel speed of the locomotive. (A dynamometer would probably use its own wheel speed or a radar speedometer to calculate power.)

Right, I don't know what I was thinking about here.

The calls to UpdateCylinders have already been changed to use the (attached) wheel speed, that is just a local variable with the same name as the global one (not confusing at all...)

Ah, fine

And yeah a crosshead pump should use the wheel speed to derive pumping speed (unusual strategies; use wheelslip to intentionally increase pumping rate). Though the energy needed to pump the water may suppress wheel slip...Looks like this could also do with a calculation of the horsepower malus, that is one of the major disadvantages of a crosshead pump.

This could be added as extra force to the axle module in the future (maybe as extra friction, but first it makes sense to move Davis A and Davis B to the axle).

These changes make sense to me, the physics related to traction shouldn't 'see' the train speed, only the wheel speed.