# Lecture 16 - Trains

## Public Service Annoucements

1. No class on Thursday, 12 February.
2. Kernel 4 due in class on 23 February.
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.

1. Drive a single train around the track knowing where it is at all times. Knowing where it is includes knowing when it will hit 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 drive two trains at once if you can't keep track 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.
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 or floating point, with all 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 3 m per minute and 180 m per hour. It will take about 1000 hours (40 days) to go 200 Km.

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 following the path created by directions of turn outs.

• As it travels it triggers sensors that give your train application feedback about where it is.
• Actually, not quite where it is. There is a time lag.
• Train triggers sensor at t: x(t) = Sn + 0 cm
• Report of sensor is recorded (time-stamped) at t + \Delta t. \Delta t includes
• interval between time of triggering and next sensor query
• time for train controller to process query and return the result
• time in your application between receiving bytes from train controller and packaging bytes into a time stamped event
You should be able to estimate each of these time intervals even though they are very hard to measure.
• At t + \Delta t: x(t + \Delta t) = Sn + \Delta x
• \Delta x = \int_t^(t+\Delta t) v(t') dt' ~= v(t) \Delta t
• In the event time-stamped at t + \Delta t the train appears to be at Sn, but it is actually at Sn + v(t) \Delta t
• Does this matter?
• How fast do trains go? Estimate 40 cm/sec.
• If \Delta t is 100 msec you are off by 4 cm.
• Does 4 cm make a difference to your train program?

How do you know where the locomotive is?

• intermittently, at a sensor
• between sensors, only by dead reckoning, which means you need to know the train's velocity

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

• A train's speed is the value you send to the train controller, an integer between 0 and 14.
• A train's velocity is the rate at which it moves along the physical tracks, a real number measured in centimetres per second.
• Some trains actually have more than fourteen velocities: they go at different velocities when you decelerate to a speed than when you accelerate to it. (Not many of these trans remain.)

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

• Velocity changes are not instantaneous.
• After the speed is changed the train's velocity changes gradually: either getting faster or getting slower.
• Tricks' that make the train stop instantly are not acceptable because they wear out the trains.
• The velocity decreases when travelling over turn outs or around curves.
• The smaller the radius of curvature the slower the velocity.
• Different locomotives travel at different velocities when set to the same speed.
• Velocity of a given locomotive decreases over time
• As the track gets dirty.
• As the time since the locomotive's last lubrication increases
• As the locomotive gradually wears out

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

• A turn-out switches while a locomotive is on top of it.
• You need to estimate where the train will be when the turn-out switches in order to know if it is safe to execute a switch command
• Locomotives run off the ends of sidings.
• You need to know how far a train will travel between when you give the stop command and when the train stops.
• Locomotives stall because they pass over difficult parts of the track too slowly.
• Why? Friction increases when a train is on curved track.
• Sensors fail to trigger, or trigger in the absence of a locomotive
• You need to know when you expect the sensor to be triggered if you are to know that it has not been triggered.

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.