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

(Version: 1)

Due Date: Thu, Mar 14, 2024, 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 some 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 a node 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.

Demo and Submission

We will be scheduling a demo with each group on the assignment due date.

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.
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.

Besides the demo, your readable and documented source code should be in your repository at https://git.uwaterloo.ca. The repository must be set to 'Private' with instructor and TAs added as 'Reporter'. Your repo should include a README-TC1 file, which describes how to make and operate your program. Each group should be working from a single repository.

Each group should submit a single PDF file into the TC1 dropbox for this course in Learn. The PDF should include the following information:

The names, userids, and student IDs of your group members.
The name of your group's code repository on git.uwaterloo.ca and the SHA of the commit that we should be using for this assignment. The commit must be dated before the assignment deadline.
A description of your work for this assignment. It should explain how you route the train, and how you get the train to stop at a target location. It should describe how you are modeling the train, including a description of any calibration data you have collected for modeling, and a description of how it was collected. Finally, it should describe how your train control system is implemented. In particular, it should describe the purpose and design of any tasks that are running, and their priorities. If you have made any modifications to your kernel to support TC1, explain those as well.
Your raw calibration data should be stored in a subdirectory in your code repository. Please identify the subdirectory in your documentation.