CS452 - Real-Time Programming - Spring 2015

Lecture 16 - Trains

Public Service Annoucements

  1. Kernel 4 due in class on 18 June.
  2. Exam schedule is out; 19.30, 5 August is the date the registrar gave us. Please bring your exam schedule to class next Monday, 15 June.
  3. PDF documents containing mathematics.

The Train Project

The Ultimate Goal

The goal for your final project is to have several trains driving continuously on the track, doing something interesting. "Interesting" is defined to exclude collisions, derailments and deadlock (no trains moving anywhere).

Two milestones

On your way to this goal you must pass two milestones, for each of which you are expected to provide a demo to the instructor and the TAs. Both the milestone descriptions will be edited in the near future.

  1. Drive a single train around the track knowing where it is at all times. Knowing where it is includes knowing when it will the next particular sensors, and being able to stop at any given location.
  2. Drive two trains on the track without losing either train, without collisions and without a 200-ton human crane lifting having to lift a train.
These demos are expected to get you doing the things that have to be done for your project in the right order. For example, there's no point in trying to know the locations of two trains at once if you are unable to know the location of a single train.

Types of Projects

Most projects over the years have fallen into one of two types. But about three years ago a third type emerged, which continues to be rare.

  1. Ordinary train projects. The trains are trains, or close substitutes like busses or taxis, and they do things like moving freight or passengers from one point to another. One recent project had trains that "broke down" on the tracks and had to be brought into a siding to be repaired.
  2. Games played on a graph. Many games are played on a graph; trains move on a graph. Making a game such as Pac-man, played by trains, is another popular project. If you do such a project be sure to make the game logic very simple, only complex enough that the trains must interact. Complex game logic usually means colliding trains.
  3. Trains that do coordinated stunts. You can devise interesting patterns created by the coordinated motions of trains. Be certain that you discuss such a project with the instructor, because it's easy to make a choice that's impossible, or even worse trivial, to implement.
  4. And, of course, anything a train can do, such as this, is interesting if you can recreate it in the trains lab.

Note on precision

We are going to be doing arithmetic. Should we do it in fixed point, which requires thought, or floating point, which has the inconvenience of increased state to save, not to mention compiler incompatibilities?

The biggest fixed point number is 2^31. How big is this? 2^10 = 10^3 = 1000, 2^30 = 10^9 = 1 000 000 000, 2^31 = 2 000 000 000.

Suppose that the smallest distance you care about is 0.1 mm. 2*10^9 of them is 200 000 metres or 200 Km, twice the distance to Toronto. At 50 cm/sec, about as fast as a train can go, a train travels about 1 m per minute, 60 m per hour, 1.5 km per day. It will take about 100 days, 30 months to travel 200 Km.

A very successful final demo runs for 15 min, 0.25 of an hour, 0.01 of a day. You have a factor of 10 000 before you will start to see round-off error.

Just for Fun. Suppose we had 64 bit words. 2^63 = 8 000 000 000 000 000 000 = 8 x 10^18. If the precision you require is 1 mm, 2^61 = 80 000 000 000 000 000 = 8 x 10^15 metres. A light year is 9 x 10^15 m, so you can travel a light year and be off by only 1 mm.

Train Properties

A locomotive travels on the track at a given speed, but unknown velocity, following the path created by directions of turn outs. When the train passes over them the turn-outs are not necessarily switched in the direction you think they are.

How do you know where the locomotive is?

Note. I try to be consistent in distinguishing between two closely related concepts: speed and velocity.

Velocity is controlled by changing the train's speed, BUT, the mapping between speed and velocity is not simple.

Important . Some of these effects matter; some don't. It's part of your task to find out which effects matter and which don't. (If you don't figure out which is which you will spend an unlimited amount of time.)

Furthermore, things can go wrong, such as

Avoiding such failures, or responding sensibly to them, is possible only if you have a `good enough' velocity calibration. (You get a perfect calibration only in the limit t->infinity, and the train you are calibrating falls over dead long before that.)

Such failures like these also pollute your attempt to acquire reliable data for your calibration.

Return to: