[roeter]

This afternoon, my OR session crashed. Not spectacular, really, but the cause of the crash was a bit surprising.
The crash was in a method of traincar.cs, and the cause was that the collection had changed during a loop operation. Apparantly, some part of the program was calculating something for a full train, while another part was detaching or attaching from or to that train. Should not really be possible, but it's just bad luck. Reran from the last save and the problem did not reoccur.

But that was not what shocked me. What had me completely baffled was the calculation where the program crashed.
It was a method named : UpdateTrainDerailmentRisk

Yes, in case you thought you misread this, it did indeed say Derailment Risk. Calculation derailment risk for AI trains? Really? :wtf01: :unknw:
Obviously, there is no intention whatsoever to derail an AI train, nomatter how the program makes it run. If the route is set up that the speed limit is 200 mph through a 100m radius curve, then that AI train will run through that curve at that speed.
So why on earth are we wasting CP time on calculations that have no use whatsoever?

And this is not the only one. There are a few more :

• Brake pressure propagation
  
• Coupler slack
  
• Drag resistance

And that's probably not all.

Now, don't get me wrong - I'm NOT saying that these calculations itself are useless. These are very sophisticated calculations which all increase the reality of the train performance - for the player train.

But, the AI train control is just basically 'rough and ready'. The 'proper' physics are first tried, increasing throttle to move the train, and applying brakes to stop it. But if the train does not react to this within the required time, the program intervenes and just moves or stops the train.

So, take for instance that brake pressure propagation. Suppose an AI train is applying the brakes as it approaches a signal at danger. The brake pressure propagation is neatly calculated using pipe diameter and who knows what other details. It calculates the resulting pressure, and with that the brake power, for each car in the train. But that train WILL STOP at that signal, regardless whether or not the brake pressure has been propagated or not. So what sense in calculating the pressure with this much detail? None, as it will not in any way affect the way the train will stop.

To make things worse - AI trains are not actually using all the new detailed parameters introduced to .eng and .wag files. Instead, they use default settings which are just as basic as the AI control itself.
So, I dare say that none of the outcome of all these calculations is used anywhere within the AI train control.

So here is my plea. Could those with knowledge of this part of the program - physics and control - have a good look at all these wonderfull calculations, and check on how usefull these are for AI trains? Most, I think, have no use at all.
So, with brake pressure propagation again as example, the present calculation must of course be maintained for the player train, but for AI trains it could just be made instantaneous. Might even improve AI train behaviour, as the train will react better to brakes being applied.
Something similar could be applied to other calculations as well.

And, of course, for that calculation of derailment risk for AI trains - could that be removed by tomorrow?

Regards,
Rob Roeterdink

[Genma Saotome]

I always thought a train is a train is a train... that they all used the same code. Guess I was wrong.... I do have a question: Why shouldn't an AI train behave exactly as a player train for at least the time when it is in close proximity with the player train (e.g., within near view distance)?

[R H Steele]

Rob...excellent observations...this should be looked into. If this is corrected it would be interesting to know some data regarding before and after performance in systems with less than optimal resources to run OR.

[darwins]

I can see the computing power argument for removing a lot of the calculations from AI trains. At the same time there is a strong case for having realistic behaviour that governs their performance. The most important things are acceleration, deceleration and fuel usage. All of these have an impact on timetable operation and what you find if you take over an AI train and it becomes the player train.

Power vs speed curve - To perform reasonably correctly the program surely needs to know the total maximum tractive force available for a given consist at any speed.

Drag - This is important as it works with the power vs speed curve to produce the acceleration, together with mass, gradient, and curvature.

Power and Drag work together to set the acceleration of a consist.

Brake power - although brake propagation might not be needed for AI, we do need to know the total maximum brake force available to set the appropriate deceleration rate on any gradient or under different adhesion conditions. It is one thing saying that the AI train will stop at the signal, but to do that the program MUST calculate how far in advance of the signal the train needs to begin to slow down, which should be different for different trains.

So we need reasonably accurate acceleration and deceleration for performance to appear realistic. This is not only important when you can see the train, but also when it is in the section ahead and you are waiting for the AI train to clear the signals.

Maybe some data can be calculated on start up and only changed if vehicles are added to or removed from the AI consist.

It should also be possible to add at least a crude estimate of diesel, coal and water usage to AI trains so that when you take these over they are in a somewhat realistic condition.

[Csantucci]

As Rob says, AI trains in some important cases override the behavior of a real train.
Some occurrences have already been mentioned, and I repeat them here together with some other cases:
1) as already mentioned, the AI train will accelerate and stop as desired, "whatever it takes", as Draghi said, if necessary and if realistic physics doesn't lead to the desired result;
2) in AI trains the air brake pipe is put at max pressure immediately after a brake release;
3) AI trains don't use dynamic braking;
4) if I remember well, throttle increase/decrease steps don't correspond to the ones defined in the .eng file;
5) if I remember well, AI trains don't slip;
... and I'm sure there are other features I'm forgetting.

So, unless these very important points aren't previously solved (which is a veeery hard task - Rob did a very good job developing the dynamic behavior of AI trains), it makes few sense to apply to them all calculations mentioned in the first post, because they are applied to a train whose basic physics laws are not respected, some during the full run of the AI train, and some in particular conditions.

[darwins]

The key question should be does it make a significant difference to AI and timetable behaviour.

Quote

1) as already mentioned, the AI train will accelerate and stop as desired, "whatever it takes", as Draghi said, if necessary and if realistic physics doesn't lead to the desired result;

This is the bit that matters - the AI train should not be able to either accelerate or decelerate at a significantly greater rate than it would as a player consist. "Whatever it Takes" should mean that a heavy consist accelerates very slowly and never reaches line speed. "Whatever it Takes" should mean that a train without continuous brakes takes longer to stop. It may stop at the signal but must start to reduce speed much earlier.

Quote

2) in AI trains the brake pipe is put at max pressure immediately after a brake release;
3) AI trains don't use dynamic braking;
4) if I remember well, throttle increase/decrease steps don't correspond to the ones defined in the .eng file;

None of these is going to make a large enough difference to AI performance to be worth the extra calculation. So I would agree not worth calculating.

Quote

5) if I remember well, AI trains don't slip;

This is an interesting one - it should make some difference - in rain and snow trains should accelerate or decelerate more slowly - so in this case probably not worth a detailed calculation, but probably there should be some constant that changes with weather conditions.

Quote

So, unless these very important points aren't previously solved (which is a veeery hard task - Rob did a very good job developing the dynamic behavior of AI trains), it makes few sense to apply to them all calculations mentioned in the first post, because they are applied to a train whose basic physics laws are not respected, some during the full run of the AI train, and some in particular conditions.

I do not know what is in the present AI calculation, but I believe it was based on trying to copy MSTS behaviour based on the parameters in the .con file. This can give reasonable behaviour for some consists and very unrealistic behaviour for others. It depends a lot on the ability of the consist builder to define the parameters. Would it be too difficult to read the eng and wag files, estimate the maximum tractive force, calculate the overall resistance of the consist, calculate the overall brake force of the consist and calculate the overall mass of the consist. Possibly some of these could be combined to give broader acceleration and deceleration constants for a consist. The values for a consist can be stored, but should be edited when vehicles are added to or removed from the consist.

[Aldarion]

Im a bit confused by this... but i was with the impression that AI trians needed some 'unnecessary' calculations because of timetable mode...

[Weter]

Yes, looking, as my timetable works, I've noticed, that AI trains don't follow $acc/$dec commands well, start 15-18 seconds after booked time. In Autopilot mode they don't slip.
And this way, we'll not be able to gain control of AI train in TT mode never, despite of Activity mode.
But, most great thing in TT mode, I suppose, is that ALL tains behave the same way as a player train.
OTOH, AI trains are drove always properly, as AI don't make any mistake, that human can, so, maybe some things, different due to player's performance MAY be standartized.
It looks like a complex question.

[ErickC]

It would also be nice if some programmer were to give the AI engineer a good hard whack over the head and tell him to stop being such a spazz with the throttle. 1 MPH or so deviation from nominal speed is probably fine. Settle down, Beavis.

[steamer_ctn]

 roeter, on 26 March 2021 - 11:59 AM, said:

So here is my plea. Could those with knowledge of this part of the program - physics and control - have a good look at all these wonderfull calculations, and check on how usefull these are for AI trains? Most, I think, have no use at all.

I agree with Rob thoughts that having full physics on an AI train would require a very complex AI model which I suspect might take a large amount of time to develop, and may not be worth the effort.

Given that the train physics have moved on a lot from when the AI train movement model was originally developed, as some users have suggested, it might also be worthwhile to review the AI models performance against any changed and realistic expectations. Whatever is developed will probably never be 100% perfect so we may need to decide what are the "must" haves, and the "nice" to have functions.

So to start some thinking, I believe that the key purposes of AI trains is as follows:

i) Provides some variety when running timetables and activities with other trains. Some might call this "eye candy".

ii) Set a realistic operating environment for the player. For this to work correctly, arrival and departure times need to be adhered to for a working timetable.

So the above two points sets a potential framework to review the AI model and physics against. Any other "must haves" as opposed to "nice to haves"?

@Rob, I am happy to work with you to remove some of the "physics" from AI trains.