CS452 - Real-Time Programming - Winter 2015

Lecture 19 - Calibration II

Public Service Annoucements

  1. Final exam: 16.00, 14 April, 2015.
  2. First Train Control Demo, Wednesday, 11 March, 2015.
  3. Don't throw away the implementation you did for kernel 4. Use parts of it to get turn-outs into alignment and get the train going when doing the first train control demo.
  4. Keep reading the sensors as the train slows to a stop, and use to readings to update your model. You need this
  5. We expect the train to find itself for milestone 2. But if it can find itself correctly the tracking software should be able to follow it as you drive it manually.
  6. When you have your tracking working it should include a prediction of the time each train expects to trigger the next sensor, and how big the error is, measured in distance.


1. Calibrating Stopping Distance

Questions you need to answer


This is very time-consuming!

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

In previous terms some groups have given not a tr 0, but instead a tr 2 command. Then,

Measuring the time to stop

In addition to the stopping distance you will want to know the time it takes to stop. Why might this be useful?

An obvious and 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.
At worst this will give you a worst case upper limit for very conservative train driving.

A better method is available if you find that the stopping distance is the same everywhere on the track. If so,

With a velocity calibration you can do the method above with better precision.

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.

To do this successfully you have to be able to give the stop command anywhere on the track.

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 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.
  3. After many measurements you build a table

Using Resources Effectively

The most scarce resources

The most plentiful resource

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

Practical Problems You Have to Solve

  1. The table is too big.
  2. The values you measure vary randomly.

The values you measure vary systematically

How much time 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.

3. Calibrating Acceleration and Deceleration

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 accelerating and decelerating. Keeping a train at a pre-determined velocity, for example, requires changing from one speed to another frequently.

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 give the train a command to change speed, we know roughly how the velocity changes.

  1. slowly at first
  2. increasing
  3. reaching a maximum, possibly for a non-zero time
  4. decreasing
  5. more and more slowly as the new velocity is approached

How should we model the process of speed changes?

The simplest possible model is a step change from the initial velocity to the final velocity. When should the change occur?

You can improve this by constructing a linear velocity change model, a bilinear velocity change model, a quadratic velocity change model, or whatever. Oral comments in class give possibly helpful, possibly extraneous suggestions.

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.
  2. Velocity along the track, specified by v(t) = x'(t).
  3. Acceleration, specified as a(t) = v'(t) = x''(t).
  4. Jerk, specified as j(t) = a'(t) = v''(t) = x'''(t)

Return to: