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

• As it travels it triggers sensors that give your train application feedback about where it is.
• Actually, not quite where it is, but where it was. There is a time lag between when the train triggers the sensor and when your application reacts to the sensor trigger.
• Train triggers sensor n at time t: x(t) = Sn + 0 cm
• Report of sensor is recorded by your application (time-stamped) at t + \Delta t. \Delta t includes
• the interval between time of triggering and next sensor query
• the 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 with the lags above taken into account, but only once you know v(t)
• between sensors, only by dead reckoning, which means you need to know the train's velocity, v(t)

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 trains remain.)

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

• Velocity changes are not instantaneous.
• After the speed is changed the train's velocity changes gradually: whether increasing or decreasing.
• 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.
• The pickup lifts as the train travels over a sensor.
• 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.