CS 452/652 Winter 2020 - Train Control (Part 1)
(Version: Feb 23 17:04:46)
Demo Date: Mon/Tue, Mar 9/10, 2020 (submit code & documentation by Mon 10:00am)
The traffic control milestones each require a capability that is likely to be useful for almost any project. The first milestone is concerned with
- knowing exactly where one train is when it is motion, and
- stopping one train at any point on the track.
For the first milestone we expect that you have the train moving at a constant velocity and can stop it at a chosen location. Given an appropriate command from the terminal your program should switch turnouts that put the train on course to the location, then send a ‘speed zero’ command at the right time to stop the train at the requested location. To accomplish this, your program must be able to
The usual way of getting the train to a constant velocity is to set turnouts to make part of the track into a loop, then to run the train around the loop until it gets to a constant velocity. Calculate a route from any switch in the loop to the destination, switch the turnouts appropriately, wait, then give the stop command at the correct moment.
- find a route to the location and switch the turnouts, and
- send the stop command at the right time.
Routing and Switching
Route calculation and switching should be as simple as possible. The route need not be the shortest and it should not require the train to change direction. (In later milestones you will be required required to use routes that change direction and that are the shortest, so do your route finding in a way that will easily accommodate those improvements.)
Switching may be done all at once, usually starting at the destination and working backward so that when the train is switched out of the loop all other turnouts are set correctly. (Setting turnouts as the train requires them will be needed in later milestones to implement switching in a way that makes it easy to reorder switching and to interleave other activities.) Routing and switching should be smart enough to behave correctly when the destination is in the loop.
Use the track information available via the course web page to build an internal model of the track(s). A stopping locations will be given as a track node number (from this data set) and a distance offset. The offset can be negative.
Stopping requires two capabilities:
We would like to be able to assess each of these independently of the other. To do so we request that every time you receive a new sensor trigger you predict the time at which you will trigger the following sensor and compare it to the time at which the following sensor is actually triggered. The difference should be displayed on the terminal in two forms: as a time difference, tactual − tpredicted, and as a distance, v(tactual − tpredicted).
- knowing your stopping distance for the speed at which you are travelling, and
- knowing when you are exactly that distance from the destination, which is possible if you know the velocity at which you are travelling.
Make sure that your kernel and/or idle task dynamically updates and prints an ongoing assessment of the recent idle time fraction. Choose a reasonable setting for "recent", but make it easily configurable at compile time.
What To Expect During the Demo
- You should expect us to want you to run the train at more than one speed.
- You should expect us to want to see destinations that are in the loop and out of it.
- You should expect us to want to give you destinations in addition to the destinations you choose yourself.
- In judging your demo we place a higher weight on your ability to stop precisely than on your ability to route and switch accurately. A demo that stops precisely at locations on your loop but cannot leave the loop is judged as better than a demo that goes anywhere on the track but stops erratically. Please take this into account when you are allocating time for accomplishing the first milestone.
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 experiments used to collect calibration information and its processing.
- 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.
- Store the raw calibration data in a separate subdirectory in the code repository and identify the subdirectory in your documentation.