# Lecture 18 - Trains

## Public Service Annoucements

1. Final exam: 16.00, 14 April, 2015.
2. In the past groups have used many different methods of calibration, and many of them worked, even though assumptions made by different students often contradicted one another. I think that this tells us something about the nature of tuning.
3. An old tuning practice that you are likely to find useful is inclusion of controls for tuning parameters in your interface. This allows you to use time running the trains more efficiently.

# Train Properties

### Speed and Velocity

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

Let's think theoretically about calibrating velocity. There's an obvious way to do it.

1. Wait until the train triggers a sensor, then measure the time, t1.
2. Measure the time, t2, when the train triggers the next sensor.
3. Calculate d/(t2-t1), which is the average velocity of the train between the two sensors.

## 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 at $t$
• train at ${S}_{n}$ + 0 cm
2. Application receives report at${t}_{1}=t+{\Delta }_{1}$
3. You give command at${t}_{2}=t+{\Delta }_{1}+{\Delta }_{2}$
4. Train receives and executes command at${t}_{3}=t+{\Delta }_{1}+{\Delta }_{2}+{\Delta }_{3}$
5. Train slows and stops at ${t}_{4}=t+{\Delta }_{1}+{\Delta }_{2}+{\Delta }_{3}+{\Delta }_{4}$
• train at${S}_{n}+y$ cm
• (You measure $y$ with a tape measure.)

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

1. The sequence of events 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.
• 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.
2. Knowing where you stop is very important when running the train on routes that require reversing
• Why are reversing routes important?
3. Clearly, knowing when you stop is equally important.

This is very time-consuming!

• The simplest way to reduce the number of measurements is to eliminate factors that are unimportant.
• The only way to know that a factor is always unimportant is to measure. Developing the ability to estimate quickly, and to find the worst case quickly is the main way of being smart in tasks like this one.

Now make a table

 Sensor 1 Sensor 2 ... Speed 6 Speed 8 ...

There are enough measurements in each cell of the table that you can estimate the random error. (Check with other groups to make certain that your error is not too big.)

Based on calibrations I have seen in previous terms you will find substantial variation with speed setting and train, little variation with sensor.

Group across cells that have the `same' value. Maybe all have the same value.

Hint. Interacting with other groups is useful to confirm that you are on track. Of course, simply using another group's calibration, with or without saying so, is `academic dishonesty'.

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

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

### Using Resources Effectively

The most scarce resources

• Bandwidth to the train controller
• Use of the train itself

The most plentiful resource

• CPU

Any time you can use a plentiful resource to eliminate use of a scarce one you have a win. For example

### Practical Problems You Have to Solve

1. The table is too big.
• You potentially need a ton of measurements
2. The values you measure vary randomly.
• You need to average and estimate error.

The values you measure vary systematically

• For example, each time you measure the velocity estimate is slower, presumably because the train is moving towards needing oiling.
• You need to make fewer measurements or use the measurement you make more effectively.

## 3. Calibrating Acceleration and Deceleration

### How Long does it Take to Stop?

Try the following exercise.

1. Choose a sensor.
2. Put the train on a course that will cross the sensor.
3. Run the train up to a constant speed.
4. Give the speed zero command at a location that stops the train with its contact on the sensor
5. Calculate the time between when you gave the command and when the sensor triggered.
6. Look for regularities.

## Train Measurement

### Measurement Noise

The story so far.

1. The time stamp of a measurement is consistently late. Subtract whenever you can.
2. The time stamp of a measurement is stochastically late. Average, or something smarter.
3. You need a map from speed to velocity. Measure.
4. The map is complex, which implies big. Look for what doesn't matter.
5. The map was created by a programmer. Look for regularities.

1. The sequence of events 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.
• 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.
2. Knowing where you stop is very important when running the train on routes that require reversing
• Why are reversing routes important?
3. Clearly, knowing when you stop is equally important.

This is very time-consuming!

• The simplest way to reduce the number of measurements is to eliminate factors that are unimportant.
• The only way to know that a factor is always unimportant is to measure. Developing the ability to estimate quickly, and to find the worst case quickly is the main way of being smart in tasks like this one.
• The less simple way of reducing the number of measurements needed is by finding regularities. "Finding regularities" is the essence of reverse engineering.

Now make a table

 Sensor 1 Sensor 2 ... Speed 6 Speed 8 ...

There are enough measurements in each cell of the table that you can estimate the random error. (Check with other groups to make certain that your error is not too big.)

Based on calibrations I have seen in previous terms you will find substantial variation with speed setting and train, little variation with sensor.

Group across cells that have the `same' value. Maybe all have the same value.

Hint. Interacting with other groups is useful to confirm that you are on track. Of course, simply using another group's calibration, with or without saying so, is `academic dishonesty'.

### 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 anywhere else, just past a switch, for example.

• You want to be close to the switch, clear of the switch, and on the correct 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.

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

### Using Resources Effectively

The most scarce resources

• Bandwidth to the train controller
• Use of the train itself

The most plentiful resource

• CPU

Any time you can use a plentiful resource to eliminate use of a scarce one you have a win. For example

## 3. Calibrating Acceleration and Deceleration

### How Long does it Take to Stop?

Try the following exercise.

1. Choose a sensor.
2. Put the train on a course that will cross the sensor.
3. Run the train up to a constant speed.
4. Give the speed zero command at a location that stops the train with its contact on the sensor
5. Calculate the time between when you gave the command and when the sensor triggered.
6. Look for regularities.

### How Long does it Take to Stop?

Try the following exercise.

1. Choose a sensor.
2. Put the train on a course that crosses the sensor.
3. Run the train at a constant speed.
4. Give the speed zero command at a location that stops the train with its contact on the sensor.
• You will need to experiment to find out exactly when to give the stop command.
5. Calculate the time between when you gave the command and when the sensor triggered.
6. Look for regularities.

### How Long does it Take to Start and then Stop a Train? How Far does it go?

Most of the your train project can get away with ignoring acceleration and decelleration. The one place you can't is when you are doing a short move, giving a speed command followed by a stop command before it gets up to speed. How far will the train go? How long will it be before the train is fully stopped?

Short moves are common when the train is changing direction, which you need to increase the number of possible paths from one point to another.

The general idea is to give the train a carefully timed series of commands knowing how far and for how long the train moves for that series of commands.

#### Procedure to calibrate short moves.

1. Place the train on the track in the sort of location where you expect to make short moves.
2. Give the train a "speed n" command, where n is big enough to get the train moving reliably.
3. Wait t seconds.
4. Give the train a "speed 0" command.
5. Measure how far the train travelled from its initial location.
6. Repeat for a range of times.
7. Build a table that tells you how far the train will travel for a given t.
8. Build an inverse table given the time needed for a move of a known distance.

Now that you know how far the train moves for a sequence of commands you can start the train that distance short of a sensor and measure the time between the first command and the triggering of the sensor.

Together with knowing when and where the train will stop if given the speed 0 command when running at a constant velocity, this will provide most projects with all the calibration they need. But you can do better.

## 4. Calibrating Acceleration and Deceleration: Doing Better

At this point you can do most of the things you will want to do for your project. But some things can only be done from a standing stop. It's more elegant to keep the train moving, speeding up and slowing down as required. To do so it's necessary fully to calibrate velocity during the act of acceleratiing and decelerating.

To explain velocity changes we must introduce models. On the track the train has a real location, so mant cm past sensor S. In your program the train has a position, so many cm past sensor S'. The model is linked to the real train by the calibration. Neither the number of cm nor even the sensor is necessarily the same in the model and in reality because no calibration is perfect. The performance of a project, such as whether trains collide or not, depends on the difference between the model and reality. The remainder of this section is based on minimizing different measures of discrepancies beteen a model and reality.

Back to real trains. When you drive a train there are four things you care about, all of which are functions of time. Particularly you care about the effects of discontinuities in them.

1. Location on the track, specified by x(t), usually anchored at the previous sensor.
• A discontinuity is teleportation, which requires infinite velocity.
• Trains do not provide infinite velocity (teleportation)
2. Velocity along the track, specified by v(t) = x'(t).
• A discontinuity is an instantaneous change in velocity, which requires an infinite force.
• Trains do not provide infinite force
3. Acceleration, specified as a(t) = v'(t) = x''(t).
• A discontinuity in acceleration, which feels like a jerk. Think of what it feels like when you are tied to a rope that is being pulled. First the rope exerts no force on you, then suddenly there is a jerk and you feel a force. Not nice.
• Do trains provide infinite jerk?
4. Jerk, specified as j(t) = a'(t) = v''(t) = x'''(t)
• We can avoid discontinuities in acceleration by having jerk constant, possibly with discontinuities.
• Thus, j'(t) = x''''(t) = 0.

### Modelling Velocity

When we model there are two distinct, but easy to confuse, things we care about:

1. where the train is on the track, and
2. where the train is in your model.

Ideally these two quantities would be exactly equal. So our goal is to minimize something like the absolute value of the difference, or the squared difference between them.

Lemma. Whoever programmed the microcontroller in the train knows a lot about trains, not much about computer science, and is lazy.

How does the location change over time if the velocity is constant?

#### Allow there to be an infinite force

Then at the right time, whenever that is, change the velocity in your model of the train

1. From the initial velocity to the final velocity.
• When do you change it?
• What error do you have in the train position when you change it at the right time.
2. From the initial velocity to an intermediate velocity to the final velocity.
• When do you make the changes?
• What should the intermediate values be.