# Lecture 16 - Trains

## Public Service Annoucements

1. Kernel 4 due in class on Friday, 16 February.
2. First train control demo is in the trains lab on Tuesday, 8 March.
3. March break open house: March 10.
4. Exam scheduled for Monday, April 23.
5. PDF documents containing mathematics.

## The Train Project

### Terminology

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.
• Saying that a train has fourteen velocities is not quite correct: they have fourteen steady-state velocities. When you change the speed of a train it does not discontinuously change velocity to a new value: it accelerates or decelerates, possibly non-linearly, to the new velocity.

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

• Speed changes are effective immediately, but velocity changes are not.
• 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
You can probably think of lots more things that would make the velocity increase. A lot of what's hard about dealing with trains, as about anything in the real world, is figuring out which set of many possibilities matters in practice.

#### Note on precision

We are going to be doing arithmetic. Should we do it in fixed point, which requires thought, software floating point or hardware floating point, which has the inconvenience of increased state to save, not to mention compiler incompatibilities? Answer. Check the amount of time your idle task runs.

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

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.
You need to know how fast trains must move to avoid stalling. How many times are you willing to give a locomotive a little push during your final demo?
• 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.
The result is sometimes a lost locomotive, which usually means stopping the demo and starting over. How many times are you willing to do that.

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.

# Train Properties

## Where is a train?

There are two methods of knowing where you are:

1. Being at a landmark: "I am at the big tree." I know that's true because I can see the big tree right beside me.
2. Knowing where you started and how far, in what direction you have travelled: "I am three blocks north of the big tree." Calculating how far you have travelled is usually done by "dead reckoning".
• Count the blocks as you walk.
• The odometre on the car integrates the velocity by counting revolutions of the wheels.
• Sailing ships threw a log over the side and counted knots.
For you project you choose landmarks
• sensors, turn-outs, etc.
• Remember the importance of fiducial marks: on the track, on the train.
You then know when the train is at a given landmark, and find a way -- most likely by integrating velocity -- to know how far it is past the landmark at any given time. If so, you need to know each train's velocity.

## 1. Calibrating Stopping Distance

The simplest objective:

• know where the train stops when you give it a command to stop
• restrict the stop commands to just after the train passes a sensor
• only one train moving

Sequence of events

1. Train triggers sensor n at t.
• The train is at Sn + 0 cm.
2. Somewhat later a task sends a command to the train controller asking it to poll the sensors. The time is t + t1. (t1 could be negative, but not too negative. How negative could it be?)
3. You receive the reply from the train controller: sensor n has been triggered. The time is t + t1 + t2.
4. You send the speed zero command. The time is t + t1 + t2 + t3.
5. The train controller receives the command and forwards it to the train. The time is t + t1 + t2 + t3 + t4.
6. Train receives the command and starts slowing down. The time is t + t1 + t2 + t3 + t4 + t5.
7. The train stops at t + t1 + t2 + t3 + t4 + t5 + t6. The train is at Sn + y cm. (You measure y with a tape measure.)
Compared to what you probably thought at first, the train was not at the sensor when you sent the command, but at Sn + v * (t1 + t2 + t3). Nor was the train at the sensor when it received the command to stop. Think. What do you want to call the "stopping distance"? This question amounts to "Why are you stopping?"

Presumably you are stopping the train because you want it to be in a particular location: before the end of a siding, before you run into another train, etc. You control only the time at which you send the stop command, which you will do after receiving some signal from the train. You are always t1 + t2 + t3 behind sensor reports; you must be t4 + t5 ahead of when you want the train to start decelerating.

#### Fiducial Marks

When you pull out the tape measure to measure y you need to know the two locations between which you are to measure.

• It's pretty obvious where the sensor is,
• but where is the train?
• the pickup? front or back?
• the front bumper?
• the back bumper?
It doesn't matter which place you choose, but it matters a lot that you always use the same place.

You have just chosen a "fiducial mark", a location you can recognize so that you can make a comparable measurement the next time. Some landmarks, switches, for example, also require you to choose fiducial points carefully.

Questions: some of which need answering.

• If you do this again, same sensor, same speed, will you get the same answer?
• If you do this again, different sensor, same speed, will you get the same answer?
• If you do this again, same sensor, different speed, will you get the same answer?
• If you do this again, different sensor, different speed, will you get the same answer?
• Or a different train, or different track condition, or ...
Which ones? How do you get to an answer? You build up some intuitions about what belongs in a model of the train.

What you are doing is building a model of the train. There are a few different ways you can reason in doing so.

• The manufacturer of the train set must make one that appeals to people who like model trains. Therefore, its behaviour must be a good-enough simulation of a real train. That's why we have gradual acceleration and deceleration.
• The programmers of the train controller ond of the locomotive microcontroller have deadlines. They will use loops rather than building many many tables of data.
• The instructor has seen a lot of projects and knows what is easy, what is hard and what is impossible. His philosophy is that students learn when they are doing something hard, but not impossible. He knows from experience that many different models have been used with varying levels of success.
• There are simple models that describe locomotive behaviour well-enough that you can calibrate a new locomotive using only a few parameters, but it's a lot of work to find them.
Building a model is as much an art as a science. The following sentence should be read carefully. The intuition you need, in order to know that you don't need to measure without measuring, can only be built my measuring!

The sequence of events described above has a whole lot of small delays that get added together

• Each one has a constant part and a random part. Try to use values that are differences of measurements to eliminate the constant parts.
• Measure more than once to get a better measurement of the constant part. But remember that the random part does not go away. It's there in the measurements you make when your project is running.
• Some delays can be eliminated a priori because they are extremely small compared to other delays. The more you figure this out in advance the less measurement you have to do.

### Measuring the time to stop

In addition to the stopping distance you will want to know the time it takes to stop. A simple way to do so is

1. Start a stopwatch when you give the stop command.
2. Stop the stopwatch when you see that the train is stopped.

This might not be accurate enough for you. When you have calibrated the velocity and can stop anywhere on the track there's a better way.

1. Give the stop command so that the train will stop with its pickup on a sensor, recording the time you when you give the command.
2. When the sensor triggers, check the time.

## 2. Calibrating Constant Velocity

At this point there are a few places on the track where you can stop with a precision of a train length or better. However, suppose you want to stop not sitting on a switch.

• You want to be close to the switch, clear of the switch, and on the right side of the switch when you stop.
• You want to know when the train has stopped because until then you cannot give the command to throw the switch.
• You want to know when the switch-throwing is complete because until then you cannot start the train running in reverse.
To do this successfully you have to be able to give the stop command anywhere on the track and know how long it will take the train to stop.

### Knowing the Current Velocity

An implicit assumption you are making is that the future will closely resemble the past.

1. You measure the time interval between two adjacent sensor reports.
2. Knowing the distance between the sensors you calculate the velocity of the train
• velocity = distance / time interval
• measured in cm / sec.
Note that on average the lag mentioned above -- waiting for sensor read, time in train controller, time in your system before time stamp -- is unimportant.
• Sensor1 actually hit at ${t}_{1}$.
• You record (S1, t1 + dt) as the first event.
• Sensor2 actually hit at t2
• You record (S2, t2 + dt) as the second event
• You compute the velocity as (S2 - S1) / (t2 + dt - (t1 + dt)) = (S2 - S1) / (t2 - t1)
• But the variation in dt from measurement to measurement adds noise to the measurement.
3. After many measurements you build a table
• Use the table to determine the current velocity
• Use the time since the last sensor report to calculate the distance beyond the sensor
• distance = velocity * time interval