[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.

[darwins]

Quote

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.

Is the big one. It could be extended to

"...arrival and departure" and passing "times need to be adhered to for a working timetable" so long as this is within the operating capacity of the consist and within the line speed limits.

I am not sure where the timetable team are at with regard to passing times, but this has been talked about and since we have a lot of long distances run without stops in Europe then it would help to maintain a realistic operating environment. AI trains should run late rather than significantly exceed their operating envelopes.

That does sort of overlap with the "eye candy" part.

If we are near to a long unbraked freight train we expect it will crawl very slowly to a stop at the signal.

If an EP braked electric multiple unit is stopping at the next platform it should come in much faster and stop much more sharply.

Similarly if we are running parallel to a train on another line we might expect it be slowed down by climbing a hill in much the same way that the player train is.


The other thing I will mention again is using coal and water. For diesel fuel, and for water there could be a very simple solution to this one. We don't see the diesel fuel or the water unless we take over the train and it becomes a player train (in timetable mode) - so it might be possible to do a quick rough and ready calculation for this based on distance from the last fuel depot or watering point, when the train is selected as a player train.

Coal is a different matter - we should be able to set the level in the bunker or tender at the start of the activity or timetable run. This is going to get lower as the train uses up coal (or wood). Accuracy is not that important, but for "eye candy" we should see different levels of coal in tenders depending on how far the loco has run.

[Weter]

Peter, I agree with the second paragrapf. Would be great, if someone revise that.
Darwin, That's very important point (about the coal&wood). I'm glad to read it.

[roeter]

Thanks for all your reactions.
Just a few quick replies :

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;
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;

AI trains are controlled at train level, unlike player train which is controlled by the player at engine level through the player engine. The player engine control and feedback run directly from the user interface to the engine and back. For AI control only two variables are available - AIThrottlePercentage and AIBrakePercentage. So, more detailed control, like dynamic brakes, throttle settings etc., are just not available for AI control. Neither are any feedbacks available like wheelslip etc.

Quote

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

Actually, they do. I did run tests using actual physics for AI trains but these completely failed, with trains running very slow or not at all. Very often, the reason was wheelslip of one or more engines. As noted above, there are no feedbacks on this so it is not possible to take this into account when controlling the train. At the time the AI control was created, it was beyond my knowledge and available time to try and sort this out. So wheelslip does occur, but due to the 'override' logic the train will move, regardless of that wheelslip. I actually think some of the trains experience wheelslip almost all of the time, with the engines not delivering any tractive effort at all.

Quote

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.

Not quite true. As created originally, there was no attempt to copy MSTS behaviour, but mainly to try to make AI trains behave as the player trains. The first attempt was to use the actual physics as much as possible, but as detailed above, this failed. So, the present 'override' logic was set up instead. The adaptions based on parameters in the .con file were introduced later to try and make the behaviour more in line with MSTS. This was included for activity mode only, these adaptations are not used in timetable mode.

Quote

Yes, looking, as my timetable works, I've noticed, that AI trains don't follow $acc/$dec commands well [...]

They do, but the effect is limited. For instance, on trains with many stops at short distances, setting $acc=3 and $dec=3 will reduce the running time between stations with about 30 to 60 secs.

Quote

[...] start 15-18 seconds after booked time.

That's a deliberate random delay. It can be changed or switched off using the #restartdelay field, see manual for details.

Quote

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

Thanks very much. I have send you a PM.

Quote

I am not sure where the timetable team are at with regard to passing times, but this has been talked about and since we have a lot of long distances run without stops in Europe then it would help to maintain a realistic operating environment. AI trains should run late rather than significantly exceed their operating envelopes.

Timetable team - well, you mean I, me and myself :discuss_gathering: ?
Passing times are on the cards, but their use is more likely related to priority control (e.g., set route for trains in sequence based on timings at locations) rather than speed control.

Quote

The other thing I will mention again is using coal and water. For diesel fuel, and for water there could be a very simple solution to this one. We don't see the diesel fuel or the water unless we take over the train and it becomes a player train (in timetable mode) - so it might be possible to do a quick rough and ready calculation for this based on distance from the last fuel depot or watering point, when the train is selected as a player train.

Yes, I have seen the discussion on that issue in another thread. It is now on my list, but it needs a lot of preparation before it can be included. There are some, still rather basic, plans for various improvements and enhancements in particular for timetable mode. But it is far too early to go into details, and it will be quite some time before any of this will become visible.
But take heart - these points are noted and, given time, may one day become reality.

Regards,
Rob Roeterdink

[Weter]

Excuse me, Robert, I must be more precise: whole numbers for $acc/$dec work fine (needed for good EMU behavior modeling, as EMU accelerate and even more-decelerate much faster, than locomotive-hauled, regular trains), but using partial numbers causes not very good results: 0,2-0,4 I tried to use for passenger trains, which need to depart very smooth from terminals.

And thanks a lot for still working for ORTS TT concept. It pleases me very much.

[Track Guy Mike]

steamer_ctn, on 28 March 2021 - 02:16 AM, said:

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.

Wouldn't you want the AI trains to perform 'properly' creating a realistic operating environment? If they follow the same physics as the player's train and those physics are producing a realistic simulation for the player's train, then they should also operate realistically for the AI. Real trains don't always hit the timetable times perfectly for every station (think long dwells due to problems loading or unloading with pasengers holding the doors open), that is why timetable schedules have 'recovery' time built into them. Train Operators and dispatchers deal with this variability daily.

The AI train should be able to easily run a proper timetable and/or produce a theroretical 'minimum time' run across the route. This behaviour is expected in simulators and train performance calculators used in the rail industry.

I think a quick check on the performance side of the question would be found in the updater routine where the real elapsed time from the last iteration of the updater times the game speed is used to update the sim time, if the resulting sim time is different the real time, then the processing takes longer than the real time and the calculations are affecting performance (I'm not describing this well), otherwise the sim isn't using the full processor capabilities. Alternately, the game speed can possibly be upped until undesirable reults occur, indicating computational issues...30X works fine for the BNSF scenic route for a single AI train on my laptop (your results may vary), so it seems to me that there is headroom in the computation cycle at that level of sim.

I'd also like the second the comment about the twitchy behaviour of the AI throttle, no driver flips the throttle back and forth in partial seconds, the AI throttle is unrealistic. Should/could a throttle change timer be instituted to skip the throttle update code until some pre-defined (and user selectable) interval has passed. 30 seconds (44 feet at 60 mph) is where I'd start... Possibly, add a low speed threshold where the throttle twitchiness is actually used to keep the train (short passenger trains and light locomitives) at 'walking speed' through a work area. It would likely be useless on a long freight drag though...

I'd be happy to assist with programming and/or testing. I'm interested in using the minimum running time part of the AI sim for a TPC style output to compare locomotive consists.

This post has been edited by Track Guy Mike: 19 August 2022 - 01:39 PM