Automated Cornfield Collision Avoidance

Problem

With DCC, two trains, coming at each other from opposite directions in the same block of track, may collide. Such collisions are known as Cornfield Meets. Dispatchers should issue warrants to all trains under management such that two or more trains do not simultaneosly share a block. There may be carefully specified exceptions, of course.

What if we want to run robot trains automatically without the intervention of a Dispatcher and if not all track block sequences are signalled?

Approach

We revised the procedure for creating Robot Trains described earlier in Manifest Scheduled Robot Trains to include block reservations using JMRI Memories prior to entering the block. We added script logic to use the Traffic Flow Control (TFC) feature described earlier (see Dispatcher  and video below).

We added logic for each block sensor to set the TFC sensors to active when the block is assigned to a train and to set the TFC sensors to inactive when the block is released.

Robot Trains can operate semi-automatically with Dispatcher controls or fully automatically if no human operators are permiited to share the layout.There is an option to choose whether or not a Dispatcher can intervene during running when a Train script is created by selecting the Dispatcher checkbox (see detail below).

Traffic Flow Control Sensors

We revised our Traffic Flow Control (TFC) architecture to support multiple Robot Trains on the layout that are likely to have "Cornfield Collisions" with one another. We recognized the incompleteness of the prior set of TFC sensors but could still use them as long as a Dispatcher could control the TFCs and issue Warrants to operators.

Moving into Robot Trains requires an expansion in the set of TFCs and the introduction of JMRI Memories to hold ownership or resevation for at most one Robot Train at a time per Block. (see footnote 1)

These TFCs are implemented with pseudo Loconet sensors so that our signalling logic can be instructed to include traffic flow control in decison making. The upgraded TFCs are shown on the partial Layout Status display image shown here.

Each TFC element is a sensor displayed as a short "yellow" line with or without an arrowhead on one end. Two TFC sensors are typically joined on one end. The other sensor line end will display an arrowhead when it is Active. One arrow points "East" and the other points "West". If an arrowhead is displayed, other restictions aside, a train can go in the direction of the arrow but cannot oppose the arrow's direction. In the above image there is a train in Big Mine Run. Notice the states of the eight signals surrounding Big Mine Run.The train can go toward Girardville or Ashland. If there were a train in Girardville or Ashland it could not go to Big Mine Run.

The signal managing trains to move from Big Mine Run to Ashland Main Line is GREEN in the above figure. The TFC shows an arrowhead into Girardville. The JMRI PanelPro control for this Se8C signal is shown below. LS3563 is the TFC without the arrowhead leading into Girardville - so a train may proceed into Girardville. The signal from Girardville Main Line to Big Mine Run is RED because the TFC with the arrowhead is denying access to Big Mine Run Main Line.

Sensor Logix to Manage TFCs and Memory Resets

An example of the Block Sensor Logix is shown below for the Girardville Main (LS297). The TFC from/to Big Mine Run block and from/to Girardville-Pottsville St Clair Yard block are managed.

JMRI Memories

We use the "Comment" field in the JMRI Memory object to control block ownership (see footnote #1). Each concurrently running train has its own thread. So each train can potentially use any Main Line or Bypass block in this implementation. If a block is reserved for one train, it cannot be reserved by another until it is released by the former train. If the block sensor is active, that is the train "most likely" in that block right now.

A snapshot of the JMRI Memory table below shows that blocks 35, 39 and 40 are reserved for test train "Cornfield_E2W_1". Notice the RED track (Block LS35). This indicates that the the loco or other sensor triggerable cars (with resistor axles) on the train are now in this block. The next block LS39 (Indian Town Gap) is reserved for this train. There is dark territory between Indiantown Gap and Shamokin (LS40), so block 39 & 40 form a Super Block. Hence we reserve LS40 also. Otherwise a train from Ashland could potentially move into the Shamokin block while our train moved into the IndianTown Gap block. A "Cornfield Meet" becomes likely since there is no Dispatcher issuing stop and reverse warrants after a stop in at least one block.

Critical Regions/Sections

There is the potential of a "critical region or section" of code occurring with this implementation when multiple threads (i.e.Robot Train Scripts) try to reserve the same Block "simultaneously". The block owner is set in the JMRI Memory variable and two or more threads could step through their copy of the code instructions virtually simiultaneously. There are advanced Jython or Java mechanisms that can manage critical sections but none have been implemented yet. Hence a "Cornfield Meet" is still possible in this version especially if your computer has multiple "core" processing logic and if your JMRI takes advantage of these core so two or more threads can each have their core processor to run their copy of scripts using the same block.

Dark territories and Super Blocks

While we have a lot of signalling on our layout, there are still a few "dark territories" where there is no signalling between blocks nor possibly for some turnouts. We call such strings of blocks: "super blocks". Main Line "super blocks" connecting two Main Line - Bypass Siding territories requires special handling as compared to sequential block by block processing. Our layout uses seven Main Line - Bypass Sidings shown highlighted below.

This video shows a simulated robot train run.

To see robot train running on my layout, click the next link.

Example of "Cornfield Meet Avoidance"

1. We tried to use the Block logic in Panel Pro but could not adequately control it . This block logic may also have a critical region issue. We have not explored the source code.