Reusing OpenRails physics code for model railways use

[cjakeman]

Chris I’ve been told that replicating model railway track is not able to be duplicated exactly and because of the discrepancies it could lead to application crashes.

Does the two descriptions of both the real and virtual have to be precisely the same? If it is can it be achieved?

Getting curves of the correct radius is not an issue as you can specify the radius and angle in Open Rails. Switches/Pointwork would take longer as these are comparable to modellers set track and new ones would have to be created with a tighter radius.

However this is side issue in order to give you proper gradients. The main issue is to get acceleration and braking acceptable on a model.

Going the other way and distilling the physics code out of train.cs have you a view on how big that code would most likely be?
I’m trying to work out if our protothrottles have enough ram to be able to process the physics basic algorithms on board. Ball park?

Some of our users are looking at 100 trains simultaneously, but here we have only one. A few kB I would guess.

*************

I've enjoyed exploring what's possible here and your ProtoThrottle looks very good to me. However I've got lots of coding commitments already, so unless you have a friendly coder on tap I can't see this going anywhere.

[Markstaffrld]

Chris I want to Thankyou so much for your guidance, without your input I wouldn’t understand that the idea I had is (with the right people onboard) was viable.

That pleases me no end. But no volunteers have come forward and I have been getting a bit of trolling by nesayers on the subject and I feel somewhat worn down.

I’m going to concentrate on building the ProtoThrottle hardware first and hope that along the way the hardware will inspire a coder to join me and try an option or two then.

But Chris I do what you to know I really appreciate your helping me and I know that your way busy and have little time. I know the feeling.

Regards
Mark

[Markstaffrld]

Back again men, I have a follow up question on the same subject.

To reuse Openrails Physics code to enhance model railway train behaviours.

Two of us have been working our way through Openrails (or should I say Greg has). With less input from me given I’m not a coders backside.

But we have been looking at
Openrails-Testing-Source/Source/ORTS.Simulaton/Simulation/physics/train.cs

This piece of code would appear to have software that is tracking slack at each coupler and covers of making sure slow acceleration is used to not break couplers.

That is all fine and good but it doesn’t seem to point us to the place where the physics of a steam engine works out how much throttle with x amount of reverser cutoff causes y amount of acceleration.

I found that

Source Orts.Simulation/Common/SteamTables.cs

Appears to have the base tables that matimatical formulars would use under differing circumstances to deliver realistic driver outcomes to throttle/cutoff and outside external inputs settings

But for the life of me, I’m not nailing down where these things “tie it all together”

HELLLLLLPPPPPP! Please!

Mark the model railway dude

[Markstaffrld]

Hi again,

I have discovered the coalstonewcastle web site.

What a fantastic resource. I think most of what I need can be found on that web address.

Have a great days guys
Mark

[cjakeman]

But we have been looking at
Openrails-Testing-Source/Source/ORTS.Simulaton/Simulation/physics/train.cs

This piece of code would appear to have software that is tracking slack at each coupler and covers of making sure slow acceleration is used to not break couplers.

That is all fine and good but it doesn’t seem to point us to the place where the physics of a steam engine works out how much throttle with x amount of reverser cutoff causes y amount of acceleration.

The acceleration of the train depends on the MotiveForceN of each loco, the effect of gravity where there's a gradient and drag due to friction, wind resistance etc.

You've been looking in the right file for acceleration.

Method physicsUpdate() runs at eachupdate cycle to calculate TotalForceN for each car in the train and ultimately the revised SpeedMpS of the train.

But to find the MotiveForceN for a steam loco, you should look into MSTSteamLocomotive.cs at method UpdateMotiveForceN()

It's all rather involved as OR caters for simple and compound steam engines and geared steam engines too.

[Markstaffrld]

Thanks Chris,

I think this job is going to take a while
Mark

[SimonME30]

Hi Mark,
I’m keen to do this for my layout.
It’s not just the physics tho, it’s the sound as well. I model in O gauge, and have a fleet of 12”:1’ carriages. I don’t want to hear a light engine getting around, with ghost carriages, I want to hear the entire train go past. Loco sound decoders just don’t do this, nor will they ever have the bass sound of a full size train.

My approach would be to model the layout in OpenRails, including the timetable (I like operation, and have the WTT for my prototype). Use OpenRails in full, straight out of the box. Use the API to extract the relevant speed and direction data, and control the models via a Wi-Fi, battery powered on board ‘decoder’. I have done the latter using ESP8266. Use the well established DCc++ comms protocol or indeed the wi-throttle protocol would also work.

Next part I would like is as you suggest, a steam centric handle held, wi-Fi loco controller.