Reusing OpenRails physics code for model railways use

[Markstaffrld]

Ah brakes,

At the moment my steam ProtoThrottle has two brake leavers. Requests have been made for multiple brake functions in a decoder. I have my fingers crossed. At worst case I make the same brake software operate for both of the leavers, sort of a or gate type of thing.

We do have one functing brake for most decoder brands at the moment though. One does get by quite nicely though brakes are an area where there is room for improvement.
Mark

ORTS.simulation, now there is a tip from heaven, thankyou.

[Markstaffrld]

I know what I’m doing for the rest of today.

[SD40-2]

Um, is there something wrong?

Also, I should get something out of the way. I'm a diesel man, in every sense. I have more diesels than steam, but I'm not a fan of the ultra modern diesels. I tend to focus on railroading from 1960s to 1990s. My future HO layout will be set in the 1990s on the ATSF.

I do like steam though, and have a few locos for when I want to do steam.

EDIT: I've been looking over the thread on MRH, I'd like to clarify things.

Open Rails uses Engine files created by other people and tend to be subject to copyrights. Because the ProtoThrottle code is open source, new engine files would probably have to be created for each locomotive. Engine files are still a great idea, and could be tied to a specific decoder address.

Somewhere, I think we left V-Scale, and moved to HO scale... I'll let one of the actual OR developers speak if they'd like to.

[SD40-2]

Also, there's parameters in a typical MSTS/OR engine file that would be completely useless in HO, such as engine size and light positions.

[Markstaffrld]

Something wrong. No not here. You pointing me to the code is great. Wonderful. Terrific, magnificent. You get it that I’m a happy man?

Once I work out a viewer I’m going to see what is what, or at least try. I’m sure I can get a flavour of what is going on anyway. As to clarifying stuff like copyrighted content. I’m sure we have a lot to learn along the way. But just looking at it and working out how one goes about doing this or that is a steep learning curve, especially dummies like me. ProtoThrottle sort of has engine “configs” that setup cv’s etc.

To add more is a extension of what is there. One question will come up and that is resources in the Protothrottle hardware May be overwhelmed by this stuff. But we need to cross one bridge at a time.

I figure finding out what can and cannot be used will be part of that learning curve. But on the other hand having capabilities that are not as yet implemented in HO Scale (I model O Scale by the way) is not a bad thing at all. If it’s there someone just may be inclined to make that feature functional. More power to them. Sorry about the pun buddy.

Anyway, I’m back to code, or at least look.

Have a good night
Mark

[SD40-2]

You're welcome, and yes, I do understand you're a happy man.

I think I'll need to buy a DCC system soon. One change at a time.

Just kinda feeling odd here that some train simulator code can make model railroading feel more realistic. And thanks for reminding me about CVs. I should've known better because I was looking at decoders recently. And I'm only 22!

[Markstaffrld]

Hi Parker, I’m three times your age. Older, slower bummer, uglier, what else, blinder.

But I guess we are both addicted to fun

[longiron]

In thinking about how OR simulator code could add some realism to model railroading use:

1. creation of engine specific behaviors - i.e. throttle lag, traction motor loading, and triggering of other decoder SFX, etc.
2. better simulation of train load - train would behave as if the train cars had realistic mass and resistance relative to the engine power. Slower acceleration and tougher grade climbing
3. better simulation of braking - since model cars have no brakes, this could be simulated by slowing the train more realistically via the engine

Here's the drawback:
A model railway route only represents a tiny fraction of the size of a simulator route. For example David Park's famous Cumberland route ( http://dpcw.borail.net/ ) has about 1200 feet of HO track, and only 243 feet of mainline run - which translates into 2,117 feet in the 1:1 world or less than 1/2 mile. It is supposed to represent the B&O from Cumberland to Terra Alta, a distance of about 70 miles in 1:1 scale. In my B&O West End simulator route, it's the same as in 1:1 - 70 miles of track!

So having a heavy train take almost 1 mile to reach 30 mph from a stop is no big deal, but would require more than the entire length of Dave Park's model railway.

Compromises will be required between realistic and model behaviors

[cjakeman]

Re being as realistic as possible. We already have “smiles”. I don’t know if this is right but I call them “small miles” smiles. And fast clocks are very common. Personally I have no particular need of either as I have a small switching layout with only a short piece of main line that immediately goes into a storage staging area. I’d be quite happy for the train to barely get up to any speed at all before disappearing off stage.

So dispose my particular use maybe distorting physics could be good thing for most if not all.

I think "distorted physics" would be best.

The simulation would not know where your loco was on the layout, so would ignore gradient and track curvature. Also it would not be able to respect signals.

It's possible for a C# program to call functions in a DLL written in C, so a special version of Open Rails could be created which would include your code.

Do you see this as a program which runs standalone inside your ProtoThrottle or as two separate programs which communicate - one in your ProtoThrottle and the other running on a PC?

[Markstaffrld]

Two Chris’s
It could get confusing. Mister B&O and other. You made me laugh out loud at that one. So it must be B&O and Victorian Railway’s Narrow Gauge then.

I figure your right about needing distorted physics. The issue may finish up being a bung fight about “how” distorted is the right amount of distortion. If possible maybe a distortion multiplier might be one way to satisfy all comers. I was thinking of asking how many people use fast clocks etc in some sort of pole and I figure I already know the answer, anything from 0 thru to say a maximum of around 8:1 with a lot sitting at 6:1.
But this is one of those you never please everyone all the time sort of discussions.

I’d like to talk about train Tonnage and track gradients for a bit. In both areas model railways are sadly deficient. There is no way to automatically “know” how much my train weighs because not only it is just a model but I am wanting different performance from my train based on knowing my train has loaded or empties and in what ratios in the consist or not. It is me and me alone that knows these facts so l think the only viable input device to load that information into the sytem is my big fat finger.

ProtoThrottle has a config (pending) that allows for end uses to set “Tonnage” to light, medium, heavy, or very heavy. I believe there is a possibility that these setting could be made to change the “momentum “ settings we current have in our decoders. If we get physics into our Protothrottles the that momentum type of control could become obsolete. Momentum could be set to zero and physics applies the precise motor request directly to the train motor.

At this time slope is not catered for at all. Personally I believe there is a need to have a similar end user control where the setting of slope could be set “on the fly” and then is mixed with all the other inputs in order to set “Tonnage” style momentum settings or alternatively if physics gets up to be part of the algorithm that sets motor speed. Just think, accidentally knock the brake off and your train could start rolling away. I have a little gleam in my eye just thinking about it. How cool would that be.

As to B&O Chris’s creating specific engine behaviours. I look briefly at your engine configuration file and my word, no wonder people want to sell them. My idea of a config was something like a comma delimited txt file that had those basic performance and capacity details that are required to differentiate between one engine class and another. No need of any artwork rendering or such. Basic details that allow physics to be applied to that locomotive that we are controlling at the time. Diesel, electric or steam.

My preference would be to have physics code embedded in the ProtoThrottle itself. But, and it’s a reasonably big but. The boys at ISE who designed and built this throttle built it with overall weight, battery life, small size, and overall costs as significant constraints on this project. So I am assuming that if the code gets embedded in the throttle then it has to be very lean&mean as I don’t think there are bucket loads of computing resources available on board.

That being said there are always more way to skin a cat as they say. Putting physics on a pc may provide plenty of computing power but may prove to have other “difficulties” translations etc.

True rail fans have two favourite railways The Victorian railways narrow gauge and the B&O. Hahaha. I crack myself up at times.
Have a great day men
Mark

[Markstaffrld]

I think "distorted physics" would be best.

It's possible for a C# program to call functions in a DLL written in C, so a special version of Open Rails could be created which would include your code.

Do you see this as a program which runs standalone inside your ProtoThrottle or as two separate programs which communicate - one in your ProtoThrottle and the other running on a PC?

Hi Chris,

I spend a good portion of yesterday reading through train.cs and only got partway through before my eyes gave out. But I found it most instructive even if I only got to brake retarding at around 3767.

19693 lines, so I only have 15000 odd to go, hahaha.

Even in that truncated read I already know there is large amounts of that code that we modelrailroaders will never ever use. I’m guessing you already knew that when you put together the words that I quoted above. Can you please excuse my playing catch up but I’m a bit slow on the uptake.

I see now the sense in you guys creating a special version. I would think even you doing the job is not an insignificant task. A lot of work indead.

But I’m thinking that without that we in model railroad land are dead in the water so to speak. On the other and having just the physics and only the physics in one place could prove to be a usefull excersise in the long run for everyone. Though Chris I can’t for the life of me come up with something tangible to justify that statement it just sort of “feels” right some how.

Even with that effort I got it that that is only the start of the journey to get those features into model railways (see I slipped back into being Australian there). Did you notice?

On another subject, have any of you looked on github at the Iowa Scaled Engineering’s section on ProtoThrottle yet. I’d love to see you fellas getting into that. I could see those consoles picking up the pleasure index for V-Scale end uses quite a lot.

I think I’m going to go back into train.cs. Cause I have a bit of a masochistic streak in me.

Mark

[cjakeman]

At this time slope is not catered for at all. Personally I believe there is a need to have a similar end user control where the setting of slope could be set “on the fly” and then is mixed with all the other inputs in order to set “Tonnage” style momentum settings or alternatively if physics gets up to be part of the algorithm that sets motor speed. Just think, accidentally knock the brake off and your train could start rolling away. I have a little gleam in my eye just thinking about it. How cool would that be.

In Open Rails, your train does indeed roll away if you mess with the brakes.

Imagine an arrangement where you have a PC running Open Rails linked to your ProtoThrottle. As well as selecting the consist (loco and train) on Open Rails to give the right mass, power, braking etc., Open Rails could perhaps contain a model of the layout complete with gradients. After all, this is what it's designed for.

Then, as you drive your model along your layout, the speed of the model is automatically controlled to match the simulation on Open Rails. We would need a way to keep the location along the track fully in sync, perhaps with a few track sensors at strategic points.

Also Open Rails provides an animated map view, so you can see where all your trains are.

Anyone could make this vision a reality, but there's a lot of work involved.

[Markstaffrld]

Imagine an arrangement where you have a PC running Open Rails linked to your ProtoThrottle. As well as selecting the consist (loco and train) on Open Rails to give the right mass, power, braking etc., Open Rails could perhaps contain a model of the layout complete with gradients. After all, this is what it's designed for.

Then, as you drive your model along your layout, the speed of the model is automatically controlled to match the simulation on Open Rails. We would need a way to keep the location along the track fully in sync, perhaps with a few track sensors at strategic points.

Also Open Rails provides an animated map view, so you can see where all your trains are.

Anyone could make this vision a reality, but there's a lot of work involved.

Yes Chris I can see that as a possibility.

We do have some software vendors that offer automation and some exciting features. The one I’m most familiar with is a product out of Germany called Traincontroller, he has three versions with differing feature sets.

From the small amount I’ve looked at in your code I suspect yours is better. I put that down to your being an open source development model. Driven by the users for the users. I’m my opinion the only way to go.

I’d put as an example of this is a true work of art software that did all anyone could ask for in the operations of simulation of carrying freight an passengers around ones layout. It printed out all switch lists for each train it monitored all loads and the appropriate allocation of car type for a given load. It managed customers and their request for traffic. It did all sort of actions that were done “in the back room” by clerks and station masters etc.
It was written by one man who had a intimate knowledge of railroad traffic management in North America.

It was called Protrak and it was written by a fellow by the name of Jim Moir, a Canadian. I purchased a licence to use the software for what I consider a bargain price. Especially when you consider just how much effort and how many years it took the man to write the program. But sadly Jim has left us, and he left us leaderless as well.

I attempted to convince his estate to donate his legacy to an open source group so that his code could live on. But my proposal was rejected.

I am saddened that that determination will mean the eventual death of Protrak. I would have loved to have seen your people taking ownership of his work. I think everyone could have become winners. Maybe if we had enough cash we could buy the code? But I’m not hold my breathe to see it it happens.

Now back to positivity.
Yes I can see that openrails and modelrailroad could be a marriage made in heaven. For example I have devices called digitrax BXPA1 that can track occupancy detect, seperatly detect locomotive details of railcom (backchannel loco info) enabled decoders. Short circuit detection and protection and each covers eight blocks a piece. Just the thing to link Openrails to a layout.

But I in my very nerdy way am not what I would call “the norm” in modelrailway circles. Most don’t do this. I think even if we had the Openrails/modelrailroad interface all sorted the railroad modelling community is not quite ready for that degree of sufistication. Don’t get me wrong, just because we are not there yet doesn’t mean that that couldn’t change, and fast. But I think a demonstration of the positive application of openrails code in the form of physics could be what is needed to kick start that growth.

To date I have had no coders from my side express an interest in helping me out. Chris do you know of any people on your side who may be willing to carve out the essence of physics stuff with me. Getting it in one bundle is the start. What to do with it then is open at this stage.

Mark

Ps what is the little blue tag looking thing in the corner where the attachment paper clip symbols are. It driving me nuts trying to work it out. See I told you I’m a nerd.

[Markstaffrld]

Chris maybe I should have a closer look at Openrails intergration directly with a model railway to see what needs to occur. You have manual and automatic running so that might be cool to see if I could get it going. I’d need a dcc interface but we might get that from existing jrmi software (another open source development group)

Defiantly worth consideration isn’t it! It might be easier as well
Mark

[Markstaffrld]

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?

I don’t know enough about the subject to have any sort of an informed view.

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?

Thanks for your input buddy.
Regards
Mark