CS 452/652 Winter 2020 - Train Control (Part 2)
(Version: Tue 10 Mar 2020 16:12:23)
Demo Date: CANCELLED
Mon, Mar 23, 2020 (submit code & documentation at 10:00am)
The traffic control milestones each require a capability that is likely to be useful for almost any project. The second milestone is concerned with driving multiple trains at the same time while avoiding collisions. Trips should be completed as fast as possible (speed, path).
Sharing the track is accomplished by moving the trains so that if they use the same section of track, they do so at different times. This is a real-time problem because arriving too early is as serious a problem as arriving too late. In this milestone, you are required to add two features to the user interface you created for TC1:
This milestone is usually accomplished by adding the following capabilities to your implementation.
- Your interface should show the current destination of each train.
- The user should be able to give a train a new destination, to which the train must move.
You must implement route finding, which provides a train with a route to a given destination. The route finder should also find routes that require the train to change direction. There are many more routes including direction changes than there are without, which is important to you for two reasons. When you include the possibility of a direction change, you can often find a much shorter route to a destination. With shorter routes, multiple trains have a higher chance for fewer overlapping sections in the their routing.
You must implement sensor attribution. When two or more trains are moving simultaneously, each sensor report is either spurious or caused by one of the trains. Your implementation should consistently attribute sensor reports to the correct train.
You must implement collision avoidance. This requires you to define a policy that makes it impossible for two trains to occupy the same location at the same time, and to implement your policy. You can avoid collisions in the time domain (slowing, pausing) and/or space domain (alternative path). However, trivial non-collision algorithms, such as only running one train at a time, are not acceptable.
Your application is expected to be robust against a 'reasonable' level of errors in sensor reports and changes in the state of the turn-outs. In addition, it should avoid typical problems, such as switching a turnout while a train is passing. The route finder should be able to respond to changes in track configuration caused by unavailability of track segments. Train control should drive a train fast enough to not get stuck.
For the demo create an application that demonstrates the success of sensor attribution in the presence of single errors, and that two trains that attempt to use the same track at the same time are prevented from doing so.
The gold standard has multiple trains on the track. Whenever a train stops at its destination it receives or generates a new destination at random. The program should run for several minutes without breaking.
A good starting point might be two trains in the same loop that follow each other while keeping a minimum distance.
- You may find that creating a track server, which maintains the current state of the track, including reservations, and which answers questions about the track from other components, is an effective way of minimizing communication overhead.
- During the demo you are certain to be asked what parts of the track are reserved. Putting reservations into your display of the track status is a good idea, and might well reduce debugging time.
- When considering design choices or trade-offs, keep in mind the overall optimization criterion that trips should be completed as fast as possible.
- On possible implementation strategy starts conservatively, making generous track reservations. You will probably notice that the more conservative the reservation system, the more time the trains spend motionless. When you think things are robust you can then make your reservations more aggressive and get better performance.
Hand in the following, nicely formatted and printed.
- A description of how to access, make, and operate your program in a README file, including the full pathname of your executable file.
- The names of your group members in the same README file.
- A description of the structure of your kernel and application so far, highlighting the changes for this assignment. Describe which algorithms and data structures you used and why you chose them.
- A description of the offline calibration that you have performed and how it is integrated in your application. Also describe if/how your application uses online (re)calibration.
- A pointer to your code repository, readable by the TAs and instructor, containing the source code of your assignment, instructions how to make the executable and the PDFs containing the documentation. The code and documentation must remain unmodified after submission until the assignments have been marked. Email the commit SHA to the TAs and instructor before 10:00am on the demo date.