Elvas Tower: Autopilot mode - Elvas Tower

Jump to content

Posting Rules

All new threads will be started by members of the Open Rails team, Staff, and/or Admins. Existing threads started in other forums may get moved here when it makes sense to do so.

Once a thread is started any member may post replies to it.
  • 14 Pages +
  • « First
  • 10
  • 11
  • 12
  • 13
  • 14
  • You cannot start a new topic
  • You cannot reply to this topic

Autopilot mode Rate Topic: -----

#111 User is offline   ATW 

  • Engineer
  • Group: Status: Contributing Member
  • Posts: 638
  • Joined: 07-January 13
  • Gender:Male
  • Simulator:MSTS Open Rails
  • Country:

Posted 22 February 2015 - 02:08 PM

I have asked this before but for efficiency calculations an controlled speeds can the second value of the .con file MaxVelocity be used for something to control this an be investigated?

#112 User is offline   Woodfyr 

  • Fireman
  • Group: Status: R.I.P. or just Retired
  • Posts: 108
  • Joined: 30-December 14
  • Gender:Male
  • Location:Maine
  • Simulator:Open Rails
  • Country:

Posted 24 February 2015 - 10:42 AM

 Csantucci, on 21 November 2014 - 11:17 PM, said:

Thank you for appreciation and for notices. :good2:
The autopiloted train is in fact an AI train with modified and added capabilities. So it uses throttle and brake exactly as an AI train does. As my disclaimer says, it is not a train imitating a real cruise control.
Dogbert, referring to closed shunting signals, do you pass them with TAB? If yes, it is a known issue that in autopilot mode you have to switch to player driven to pass such signals. If instead player train passes them without TAB, I have to check further the code. At a first glance I found nothing about such behavior.


Autopilot as implemented in OR is very erratic, or to put it another way "Jerky" ! Braking applications of 1/2 to 1 second, full sacale and back is not prototypical. And, I have seen NO use of dynamic brakes in any scenario. The same is true for throttle apps.

It appears that some PID control (Propertional, Integral, Derivitve)(or Gain, Reset, Rate) is needed to smooth things out. This is not rocket science and is the basis for most industrial controls. Back in the "Ole" days this was done by "feel", then mechanically, then pneumatically, then electrically and finally digitally. http://en.wikipedia..../PID_controller gives a fairly good description of the algorithm of what I am talking about.

This is meant as an observation and hopefully constructive criticism of what is a really great undrtaking. My chapeau is off to the develpment team.

Russ G.

#113 User is offline   Csantucci 

  • Member, Board of Directors
  • Group: Status: Elite Member
  • Posts: 7,000
  • Joined: 31-December 11
  • Gender:Male
  • Country:

Posted 24 February 2015 - 12:28 PM

Russ,
I cannot pretend from you that you have read the whole long thread. However, pls. read the first sentence of the first post, and post #8.

#114 User is offline   Woodfyr 

  • Fireman
  • Group: Status: R.I.P. or just Retired
  • Posts: 108
  • Joined: 30-December 14
  • Gender:Male
  • Location:Maine
  • Simulator:Open Rails
  • Country:

Posted 24 February 2015 - 12:47 PM

 Csantucci, on 24 February 2015 - 12:28 PM, said:

Russ,
I cannot pretend from you that you have read the whole long thread. However, pls. read the first sentence of the first post, and post #8.


Duly noted and, Yes, I have read all. Again, an observation and food for thought for the future.

OR has been a great way to keep this old brain working. Although the learning curve gets a bit steep at times.

Happy to be back after a 7+ year absence.

#115 User is offline   Matej Pacha 

  • Engineer
  • Group: Status: Contributing Member
  • Posts: 571
  • Joined: 08-December 10
  • Gender:Male
  • Location:Slovakia
  • Country:

Posted 26 February 2015 - 11:58 AM

 Woodfyr, on 24 February 2015 - 10:42 AM, said:

It appears that some PID control (Propertional, Integral, Derivitve)(or Gain, Reset, Rate) is needed to smooth things out. This is not rocket science and is the basis for most industrial controls. Back in the "Ole" days this was done by "feel", then mechanically, then pneumatically, then electrically and finally digitally. http://en.wikipedia..../PID_controller gives a fairly good description of the algorithm of what I am talking about.
Russ G.

Hi, I understand to your observations and personally I would like to see smoother performance too. But this autopilot feature is a tool for activity debugging rather than a player replacement. But I would like to comment on your PID direction of your suggestion - a train movement is strongly nonlinear system with combination of continuous and discreet/step systems. It would be impossible to use any form of PID controller even on single train consist. Doing it in general for any consist or any locomotive with any type of traction characteristics is just a very bad dream. However, there are other simple ways how to do it - using deterministic nonlinear controllers. The biggest advantage is infinite stability and robustness of such controllers. But even there you need to setup some consist specific parameters such as acceleration limits and a time delays of the commands (such as the break system reaction time).
My comment is based on some experience with real world speed controller and also based on one-year intensive research and simulations in this field. It is not ment as an offence, it is just a comment on how things work in real world. Finally, it is ment to be a full stop of such discussion direction here, but I would be happy to discuss it in another thread.
In my opinion, the way the autopilot controlls a train is a good work. We will definitely work on a better form, but as always - this is a good start, but everything takes some time to be done.

Best regards
Matej

#116 User is offline   Woodfyr 

  • Fireman
  • Group: Status: R.I.P. or just Retired
  • Posts: 108
  • Joined: 30-December 14
  • Gender:Male
  • Location:Maine
  • Simulator:Open Rails
  • Country:

Posted 26 February 2015 - 12:38 PM

 Matej Pacha, on 26 February 2015 - 11:58 AM, said:

Hi, I understand to your observations and personally I would like to see smoother performance too. But this autopilot feature is a tool for activity debugging rather than a player replacement. But I would like to comment on your PID direction of your suggestion - a train movement is strongly nonlinear system with combination of continuous and discreet/step systems. It would be impossible to use any form of PID controller even on single train consist. Doing it in general for any consist or any locomotive with any type of traction characteristics is just a very bad dream. However, there are other simple ways how to do it - using deterministic nonlinear controllers. The biggest advantage is infinite stability and robustness of such controllers. But even there you need to setup some consist specific parameters such as acceleration limits and a time delays of the commands (such as the break system reaction time).
My comment is based on some experience with real world speed controller and also based on one-year intensive research and simulations in this field. It is not ment as an offence, it is just a comment on how things work in real world. Finally, it is ment to be a full stop of such discussion direction here, but I would be happy to discuss it in another thread.
In my opinion, the way the autopilot controlls a train is a good work. We will definitely work on a better form, but as always - this is a good start, but everything takes some time to be done.

Best regards
Matej


I concede. That puts you at least one generation in control theory beyond me. :lol2:

"Close is only good in horeshoes and hand grenades!"

Russ G.

#117 User is offline   Genma Saotome 

  • Owner Emeritus and Admin
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 15,350
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 26 February 2015 - 01:18 PM

Carlo, not meaning to open up and spill a can of worms... but might you explain why AI trains do not behave like player controlled trains? One would thing a train is a train is a train... but obviously not here. I'm just curious....

#118 User is offline   ATW 

  • Engineer
  • Group: Status: Contributing Member
  • Posts: 638
  • Joined: 07-January 13
  • Gender:Male
  • Simulator:MSTS Open Rails
  • Country:

Posted 26 February 2015 - 04:38 PM

I like to know the same thing too as I wonder how an very underpowered consist with unit's off an a single MP15DC was able to pull up a 2.5 grade with 7000 tons getting to track speed.

#119 User is offline   roeter 

  • Vice President
  • Group: Status: Elite Member
  • Posts: 2,424
  • Joined: 25-October 11
  • Gender:Male
  • Country:

Posted 26 February 2015 - 05:16 PM

 Genma Saotome, on 26 February 2015 - 01:18 PM, said:

Carlo, not meaning to open up and spill a can of worms... but might you explain why AI trains do not behave like player controlled trains? One would thing a train is a train is a train... but obviously not here. I'm just curious....

I'm a bit lost as to what differences you are refering to, but here's a few pointers.

A player 'learns' how to control the train. In time, he (or she, even if that's pretty rare ...) knows how the train will react to throttle control, e.g. how much throttle can be set before the train starts slipping etc., and also how 'sluggish' a brake application or release can be, taking this into account when braking is required etc.
But there is no opportunity for AI to learn trains in the same way. That would require a large database with all engine and consist information - that's not only complex but pretty inpractible. So things are a lot more 'rough' when it comes to AI train control.

Also, sometimes errors are made by the player, some at the 'safe' side, like an 'undershoot' when braking, perhaps even unintentionally coming to a full stop, some at the 'wrong' side, like overshooting a platform or a signal.
But such errors can not be allowed for AI trains, so certain 'overrides' are installed to ensure this kind of thing does not happen.

Another major difference is the way the train is controlled.
The player controls the train from an engine and has a large set of controls, depending on the type of engine. There are also a number of items reported back to the player through the engine like wheelslip.

For AI, however, control is only possible at train level, and the controls are very limited : throttle percentage and brake percentage only. Also, there is no feedback report of any sort - including no reports on wheelslip.
So, all AI control can do, is, if the train has to start moving or accelerating, to apply a specific throttle percentage. If the train does not move quickly enough, throttle is increased. If throttle is at maximum and the train still does not move enough, a physics 'override' kicks in and that will move the train - as simple as that.
The same applies to braking : the 'normal' physics are tried first, but if this does not slow the train enough, the program takes control and will stop that train.

It would be nice if the 'real' physics could be used, which could indeed lead to AI trains 'stalling' on banks, but that will need a lot of work on AI train control, including, as a major item, better protection against and reporting of wheelslip. It will also need much better information on characteristics and behaviour of braking systems per consist, expected acceleration and braking characteristics based on engine capacity and consist details, etc. etc.

A little test where the 'overrides' were disabled showed that trains which had no problems accelerating and climbing certain banks when run as player train, hardly reached even half of the normal speed and stalled on the first rising gradient. The main reason was wheelslip, and this particularly affected push-pull trains in 'push' mode as in that situation all power was applied through the rather light-weight driving trailer. Remember that AI control can take no action on this as it is not reported back to the AI control.

Given the enormous amount of problems I had when creating the train control, in particular of getting all trains to stop when and where required, I would be VERY VERY VERY reluctant to make any changes any time soon.

Regards,
Rob Roeterdink

#120 User is offline   gpz 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,772
  • Joined: 27-October 12
  • Gender:Male
  • Location:Budapest
  • Simulator:OpenRails
  • Country:

Posted 26 February 2015 - 11:00 PM

Matej is developing a kind of a real cruise control. Maybe if a locomotive will be equipped with (configured for) such a logic, it will be worth making a try to give it a control even as running AI. But it is the future, not the present.

  • 14 Pages +
  • « First
  • 10
  • 11
  • 12
  • 13
  • 14
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users