I don't know if this helps - but let me explain how automated trains under warrants use signals.  Perhaps this scheme or a variant of it could be used by robot throttle.

The file, xml/signals/signalSpeeds.xml, has some names for speeds in the element, <aspectSpeeds>.  There is nothing particularly special about the names, with but one exception that will mention later.  Each name keys a number, which auto-trains use to be a percentage of the normal recorded speed.  For whatever Signal Mast system is used, the aspects.xml should be edited so that each aspect has an <speed> element keying one of the <aspectSpeeds> names.  For example in xml/signals/basic/aspects.xml:
      <indication>Proceed preparing to stop at next signal</indication>
where in xml/signals/signalSpeeds.xml:
Also in xml/signals/signalSpeeds.xml is the element <appearanceSpeeds> whose members key Signal Head beanName appearances to the speed names. e.g.

There is a class, jmri.implementation.SignalSpeedMap that will convert the file, xml/signals/signalSpeeds.xml to code and the public static method, jmri.jmrit.logix.Warrant.getSpeedMap() will fetch this class.

Code lines such as:
        String speed = Warrant.getSpeedMap().getAppearanceSpeed(signal.getAppearanceName(appearance));
        String speed = Warrant.getSpeedMap().getAspectSpeed(aspect, signal.getSignalSystem());
will get the speed name from Heads or Masts respectively.

And finally, a code like:
Warrant.getSpeedMap().getSpeed(speed );
will return the speed name number as a float.  This number could be a throttle setting or whatever might be useful to Robot Throttle.

For me, I divide by 100 and use it as a ratio of the normal recorded speed.  Also, there is a Logix action that can modify this ratio for when the consist is heavier or lighter or when different power is used.

There is some flexibility in this scheme in that new speed names can be added and defined in xml/signals/signalSpeeds.xml (and used in Signal Mast aspects.xml files).

Above I mentioned an exception to the speed naming.  The only hard coded names I use are "Normal" and "Stop".  This is for cases where blocks (entrance Portals) have no Head or Mast and I use the raw occupancy detection to control speed.

A limitation of the scheme is that the same ratios are used for all engines.  The ratios for a given engine could be part its description in the Roster.  For now, I would prefer to keep things simple.


--- On Tue, 3/1/11, Giorgio <xntcp.interface@gmail.com> wrote:
One of the reasons I never used SSL is because I found it to be too US oriented and I encounter the same problem when following this interesting thread.
Please don't forget that JMRI is used all around the world :-)

Automation tools should likely deal with signal aspects (e.g. "diverging"), rather than with appearances. A US "yellow" signal may correspond to a "green-yellow" in Germany, "red-green" in Italy and so on.

Speeds cannot be expressed in MPH (what about Km/h?).  Moreover consider the possibility of identifying speeds with names, rather than with numbers, i.e. user defined strings like "slow", "20MPH", "30Km/k" and then matching them to throttle settings (0. to 1.0) for each locomotive, taking into account also the fact that the same signal aspect may impose different speed limits to different trains. In Italy, for instance, there are 4 categories of trains, which are allowed 4 different speed limits. See example: http://www.ansaldo-sts.com/IT/Common/files/AnsaldoSTS_img_proj_big/proj_av_it_big.jpg

The same applies to turnouts.  A diverging turnout can impose, nowadays, different speed limits depending on how it's build. On standard Italian lines there are turnouts designed for 30, 60 and 100 Km/h. On high-speed lines, limits can be higher.

Please, oh please, look at adding west/North length and East/South length fields.
If my train is approaching a Turnout from the points side I want to know that the block is shorter for stopping than if the turnout was at the start of the block when going the other direction. This would also help on grades where one direction is up and the other down.

Walt, I think there is here some confusion between block length and braking distance.  It's true that the length of a block can vary depending on where the train enters and exits the block (think about a block containing all the turnouts of a ladder), but the desired braking distance (in order to reach the stop point) it's a different concept and should likely be kept separate.  As far a I understand, you would like to use block lengths to determine the stop point, but others may already use them for different purposes (e.g. metering train speed or computing train mileage).

Ciao from Italy


-----Inline Attachment Follows-----

Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev

-----Inline Attachment Follows-----

Jmri-developers mailing list