CS 452/652 Winter 2023 - Train Control (Part 1)

(Version: 1)

Demo Date: Thu, Mar 16, 2023 (submit code & documentation by 9:00am)

Introduction

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.

Description

For the first milestone we expect that you have the train moving at a constant velocity in a loop 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, if necessary, 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

find a route to the location and switch the turnouts, and
send the stop command at the right time.

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.

Stopping

Stopping requires two capabilities:

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.

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, t_actual − t_predicted, and as a distance, v(t_actual − t_predicted).

Calibration

Your train model needs to have a component that estimates the actual velocity of a train for a particular speed setting as well as the stopping distance. You can perform offline calibration experiments to obtain such estimates and should probably do so to seed your model. In addition, you can update your model during the runtime of the application.

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. Switching may be done all at once. It might be safest to start at the destination and working backward so that when the train is switched out of the loop all other turnouts are set correctly. 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 location will be given as a track node number (from this data set) and a distance offset. The offset can be negative.

Later milestones will require improvements, such as shortest-path routing and on-demand switch setting - keep that in mind in your software design.

Kernel

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.

Note

It is useful to keep and add to the functionality of the interactive terminal developed for K4 - both for testing and demonstration purposes.

If you want to get a head start on later objectives, one suggestion is to implement cohorting (trains follow each other at a constant distance) in a loop.

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.
IMPORTANT: It is more important to stop precisely than to switch accurately. A demo that stops precisely at locations on the loop but cannot leave the loop is 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

Hand in the following, nicely formatted and printed.

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 documentation (see below). The code and documentation must remain unmodified after submission until the assignments have been marked. Email the commit SHA to the instructor before the deadline.
A description of how to access, make, and operate your program in a README file, including the full pathname of your executable file, which we might download for testing.
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. We will judge your application primarily on the basis of this description. 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.
Store the raw calibration data in a separate subdirectory in the code repository and identify the subdirectory in your documentation.
Note that we intend to perform code reviews with students. A TA and/or instructor might contact you to set up a (virtual) meeting.